Rollback/Commit Behavior

Because the streaming framework is designed to handle large files, regular JTA transactions cannot be used. Using regular transactions would cause transaction timeouts and memory issues.

To achieve data integrity, the concept of "long" transactions is introduced. This is a lock-based mechanism that allows intermediary commits to the database. The lock is enforced by the security manager to shield these objects from access until the lock is removed. Only the internal users can access these temporary objects.

The difference between a regular JTA transaction and a "long" transaction, is that data is committed to the database with an insert lock code ('I-<XXX>', where XXX is a unique trans- action identifier). A rollback is simulated by setting the lock code field to the value 'D' (mark for deletion). A scheduled job is provided to purge these marked value objects, and can be configured to run at specific times.

A commit is simulated by removing the insert lock of the affected value objects. As soon as this update is committed, the changes become visible for other users that would normally be able to see those value objects (data owner).

If the application server crashes, or the database server becomes unreachable during the run of a long transaction, the already persisted objects remain in the database. This is stale data.

Periodically the SYS-CleanupDatabase job checks for entities older than a configurable period with an insert lock code. If such entities are found they are removed from the system.

Based on the error level of the encountered validation errors, a decision is made to rollback or commit the changes.

This is done as follows:

If the collector contains no events, the resulting value objects will be committed and the related communication object will move to the processed state.

If the collector contains only warning-level events, the resulting value objects will be committed , but all encountered validation warnings will be added as processing history to the top-level value object and as communication history to the related communication object. The communication object will move to the processed state.

If the collector contains error-level events, the resulting value objects will be rolled back, the related communication object will move to the failed state, and any encountered validation errors will be added as communication history to this communication object.

Please note that long transactions only support new value objects (changes to existing data cannot be rolled back).