Skip to content

Object Adapter

Jan Wiemer edited this page Feb 1, 2021 · 6 revisions

Object Adapter

The concept of the JACIS is to provide a private workspace for each transaction - the TX-View - containing a transaction local copy of the original object. This includes the need to copy the objects to the TX-View and back to the store. By default this is done using the Java cloning mechanism but this default behavior can be adapted by setting a different object adapter at the object type specification for the store.

An object adapter has to implement the JacisObjectAdapter interface and the instance of the object adapter is passed to the constructor of the object type specification (class: JacisObjectTypeSpec). Alternatively it can also be set with the method setObjectAdapter.

As mentioned the default object adapter uses cloning to copy the objects between the store and the TX-Views. This implies that in both areas (store and TX-View) the objects are stored in the same format (as objects of the specified class). Generally this is not required for all implementations of the object adapter. It could also be possible to store the committed objects in a different form (e.g. in binary format or compressed). As an example the JacisJavaSerializationObjectAdapter object adapter uses Java serialization to convert the objects to byte arrays which are stored internally. Note that in this case it is not possible to skip copying the objects by providing the object in read only mode. Therefore the object adapter is also responsible if and how read only objects can be provided avoiding the need to clone the objects. For the default implementation this has already been discussed in the Read Only Objects chapter.

The following methods have to be implemented to fulfill the JacisObjectAdapter interface (the type parameter TV defines the external type of the object in the TX-View, the type parameter CV defines the internal type of the comitted objects in the store):

TV cloneCommitted2WritableTxView(CV value);

Clone a committed object to a writable TX-View of the object.

CV cloneTxView2Committed(TV value);

Clone a writable TX-View of an object back to the store of committed objects.

TV cloneCommitted2ReadOnlyTxView(CV value);

Clone or prepare a committed object to a read only TX-View of the object.

TV cloneTxView2ReadOnlyTxView(TV value);

Clone or prepare a TX-View of an object to a read only TX-View of the object.

Object Adapters Supporting Read Only Access

Object adapters supporting a protected read only access to the committed instances usually store these committed instances in the same form (class) as the original object (otherwise the objects have to be transformed to the outside view of the objects for each access). The committed objects are stored in read only mode and if a writable version of the object is requested the committed object is cloned and the read only mode adapter (JacisStoreEntryReadOnlyModeAdapter) is used to switch the clone to read write mode. The abstract AbstractJacisCloningObjectAdapter class implements this functionality only leaving the way how the objects are cloned open by delegating this to the abstract cloneValue method. There are two standard implementations of the object adapters deriving from this abstract class:

The default implementation is the JacisCloningObjectAdapter based on the Java clone method. Using this implementation requires the value objects to implement a proper clone method. The advantage is that this implementation can be streamlined to clone the objects with maximum performance. The drawback is that the clone method has to be implemented (and maintained).

An alternative implementation is the JacisMicrostreamCloningObjectAdapter implementing the cloneValue method based on the MicroStream serialization implementation. This avoids the need to implement the clone method.

Next Chapter: Read Only Mode Adapter