Concepts
In this chapter the basic concepts behind the JACIS are described.
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
|
From the description above it becomes clear that the objects stored in a JACIS store have to fulfill some requirements:
-
The objects in the stored are always accessed by a key meaning the objects are stored in the JACIS like in a Java
Map. -
The objects have to be enclosed entities not directly or indirectly referring other objects stored in a JACIS store. References between different objects stored in the JACIS stores have to be avoided. Instead only the key of the referred object should be stored. To simplify the usage of the reference a get-method expecting the store containing the referred object as parameter can be provided.
-
The objects have to be "cloneable". By default the Java clone method is used meaning that the objects have to implement the
java.lang.Cloneableinterface (or theJacisCloneableinterface) and provide a proper implementation of theclonemethod. Note that the clone operation should clone the whole object representing the entry of the JACIS store (see above). There is an extension mechanism allowing to use a different method to clone the objects (see below).
An application using the JACIS library may want to use more than one store for different types of objects.
All stores used inside an application are stored in the JACIS container (class: JacisContainer).
The JACIS container is also the API entry point. It provides the factory methods to create the stores used by the application.
All stores obtained from a single JACIS container are handled together with in a single transaction.
This means that a transaction is created for all stores in the container.
Once the transaction is prepared / committed / rolled back all sub-transactions for the stores are prepared / committed / rolled back.
By default the transactions are managed locally at the container (use the beginLocalTransaction method), but this behavior can be chaged by an extension mechanism (see chapter Transaction Adapter).
Next Chapter: Installation
