Home > Release Notes

4.2.9

Release Date: December 3, 2007

Bug Fixes

• 01533 When a new branch or a new version is created, if database commit fails, the home is not cleanly removed from cache.

• 01579 When marking a decision at level n, the gui must detect if there are other modifications at levels 0 to n-1. If not, the decisions must be automatically and recursivly impacted on upper levels.

• 01588 When modifying records, the display is, by default, inherited. For quick tabular input, input field should be available.

• 01590 On Manager, when a homes comparison is requested, versions displayed under each branch are not correctly sorted.

• 01593 ConstraintOnNull is checked on field validation within EBX.Manager even if osd:checkNullInput="false" .

• 01594 ConstraintOnNull is not checked on adaptation validation (validation report) when osd:checkNullInput="false" .

• 01565 Occulting definition mode is not taken into account by osd:tableRef during validation process.

• 01596 If the definition of a table primary key is changed, for example a new field is added to the key, then existing occurrences become invalid since they have an incomplete primary key. Such a situation is not handled: occurrences are loaded and this lead to errors when the table is accessed.

• 01597 On Manager, branch or version description with "carriage return" may cause an exception when displaying this information.

• 01598 On Manager, contrary to branch creation, version creation needs to have a defined version identifier (ie no possibilities of automatic timestamp).

• 01599 No size limit is set to branch/version description.

• 01600 On Manager, if a user has no right to export a branch, the message displayed is wrong ("You haven't sufficient rights to do import").

• 01601 On Manager comparison interface, if the user has decided to apply all differences, the confirmation message must be adapted accordingly.

• 01602 On Manager, archive page has not the correct labels for versions.

• 01603 On Websphere 6.x, the preload process fails because JNDI reference of the datasource cannot be resolved.

• 01604 On Manager comparison interface, a NullPointerException is thrown when importing archive with change set that contains a deleted record which doesn't exist in the target branch.

• 01605 When importing an archive, if an extra instance on left tries to modify an existing instance on right, the modifications are not applied.

• 01606 On Manager comparison interface, a non user-friendly error message is displayed when merging branches with inconsistent decisions (error message is "NullPointerException").

• 01607 The order of updates that are applied when a branch is merged is sometimes incorrect, regarding instances' parent-child relationship (reproduced only on JDK 1.5).

• 01609 The import with archive including « Only branch modifications » may failed when a parent adaptation has not been modified but one of his child has been modified.

Performance enhancements

Table operations

In order to improve the speed of operations in tables, indexes are henceforth managed in EBX.Platform engine.

EBX.Platform features such as instances inheritance, advanced life-cycle (versions and branches) and flexible XML Schema modeling, have led to a particular design on index, that can be summarized as follows:

• Level 1 indexes maintain a data structure on raw table blocs. Raw table blocs form basic persistence units that can be shared by multiple versions and branches.

• Level 2 indexes maintain a data structure on a full table as it is defined in a branch or in a version, however it does not take into account instances inheritance. Level 2 aggregates level 1 indexes.

• Resolved access to tables (taking into account instances inheritance), that is available through Request API or through EBX.Manager User Interface, works on level 2 indexes and uses more efficient algorithms than before.

The impacts on performance are the following:

1. Once indexes have been built, the access to a table without specific filter and sort is almost immediate.

2. Once indexes have been built, if the user has applied a specific filter or if the table access depends on a programmatic rule, the access to a table should be quick. More precisely, it depends on the cost of the specific filtering algorithm that is executed on a fetch of at least 2,000 occurrences.

3. Both use cases above guarantee an access time that is independent of the size of the table and provide a view sorted on primary key ascendant order. If the table is specifically sorted, then the first access time depends on the table size according to a N log(N) function (where N is the number of records in the resolved view).

4. If indexes are not yet built, additional time will be needed:

   • If level 1 is ready but level 2 index is not yet loaded or has been unloaded, the built time is BL2 = o(N log(N)) . 

   • If level 1 indexes are already available in persistent cache but are not yet loaded, the time to load them is LL1 = o(N) . 

   • If level 1 indexes have not yet been written in persistent cache, the time to load them is BL1 = o(N) . This is the worst case because it implies to load all blocs.

Furthermore, creation of new occurrences ("records insert") now depends on level 1 index. Hence, a creation becomes almost immediate if level 1 index is loaded.

Archive export

In archive export, a new setting, setDifferencesWithMinimalContentsOnRight , has been added for reducing the export time and archive size.

For exports whose change set is small regarding the repository size, the expected performance gain is several orders of magnitude.

The option is available on Manager archive export page and also through API (see setDifferencesWithMinimalContentsOnRight ).

Resolved comparison

The resolved comparison has been strongly optimized in the following case: the comparison is made between the same tables belonging to two different homes and those tables have no difference neither in their own instance nor in their ancestor instances.

If the resolved comparison is made between two large instances with same reference and belonging to two different homes that have a relatively limited number of differences, then the expected performance gain is several orders of magnitude.

Better memory management

When a branch or a version was closed or merged, its associated content and validation state were not released from Java object cache. In cycles involving many branches and versions creation and merge, this led to poorer performance since objects actually used tended to be reloaded more frequently.

Persistent lock improvements

If a procedure involves only read-only operations like XML export or archive export, then this procedure is no more blocked by a persistent lock.

Furthermore, a persistent lock on Reference branch does not, henceforth, prevent branches and versions management.

Other changes

Request API

A new traversal protocol on RequestResult is now provided. This protocol, based on method nextAdaptation is more adequate than getAdaptation , because in the default "READ UNCOMMITTED" isolation level , it supports transparently a concurrent deletion on the tables viewed.

Behavior concerning schema changes

As explained in bug #01596, if the definition of a table primary key is changed, for example a new field is added to the key, then existing occurrences become invalid since they have an incomplete primary key. Such a situation was not handled: occurrences were loaded and this led to errors when the table was accessed.

For preventing such situations, the records whose primary key is incomplete are now ignored at load-time and errors are logged into persistence.log and kernel.log . For retrieving those records before any modification, it is necessary to change XML Schema document to the previous definition.

Constraint on null value

Additional checks are performed concerning the XML Schema declaration of a ConstraintOnNull . 

Home > Release Notes