Concepts

In this chapter the basic concepts behind the JACIS are described.

Transaction Views and Optimistic Locking

The basic concept of the JACIS is a private workspace model combined with an optimistic locking concept. Each read access (step 1) in context of a transaction first copies a clone of the object to the private workspace of the transaction (step 2). The private workspace is called the TX-View of the store (class: JacisStoreTxView), the object cloned into this workspace is called TX-View of the object (class: StoreEntryTxView). Modifications are only done on the TX-Views of the objects in the store (step 4). As long as the transaction is active the original objects in the store are not touched. This ensures that no other transactions can see the modification. The modifications on the objects are only written back when the transaction is committed. Note that the core JACIS functionality does not include a generic dirty check for the objects in the TX-View of the store (however this can be added by an extension). Therefore only objects that are explicitly marked as updated (by calling the update method of the store) are written back. Before committing a transaction the commit is prepared (step 5). The prepare call itself may fail causing the whole global transaction to be rolled back, but if the prepare call succeeds a later commit call should not fail. Specially optimistic locking errors should be raised during the prepare call, not during the commit call. Therefore in the prepare phase a version check is done for all objetcs that should be written back during commit. If the version of the original object in the store changed since the object has been cloned to the TX-View, an optimistic locking error is raised (a JacisStaleObjectException is thrown). If the version check is passed without an error the object is marked as locked for the preparing transaction. Later all other version checks for other transactions on this object will fail. The commit of the transaction (step 6) will finally write back the changed object to the core store of original objects and release the lock marks set in the prepare phase.

Step 1: Client calls get(X)	Step 2: Object X is cloned to TX
Step 3: Object X(TX) is returned	Step 4: Client updates Object X(TX)
Step 5: prepare TX: Object X is locked	Step 6: commit TX: Object X(TX) cloned back to X