Multi-User Scenarios

A SessionContext is an expensive-to-create, threadsafe object intended to be shared by all application threads. It is created once, usually on application startup, from a Configuration instance. A BeanPool is an inexpensive, non-threadsafe object that should be used once, for a single request (single unit of work) and then discarded. The CurrentBeanPoolContext interface defines the contract for implementations that know how to scope the notion of a current bean pool. ThreadLocalCurrentBeanPoolContext, which maintains current bean pools for the given execution thread, is provided as an example implementation of this interface.

The specification of JAXR does not support transactions or locking. CSAF and CentraSite's implementation extend the API with some locking and transaction capabilities. Here are some points to note:

Transactions are handled internally and control over them (including isolation, demarcation, and so on.) is not exposed through CSAF. There is only support for bulk operations by using the BeanPool.delete(java.util.Collection) and BeanPool.update(java.util.Collection) methods. These methods guarantee the atomicity of the performed operation. There is also a BeanPool.flush() which performs one bulk operation for the deleted beans and one for the created and updated beans.

Each modification to a registry bean (RegistryBean instance) leads to obtaining an exclusive lock for writing on the whole registry object in the database. This is a pessimistic locking strategy, as the lock is obtained when the object is modified and not when it is actually persisted.

Whenever a lock on a registry object cannot be obtained (because it is taken by another client), the following exception is thrown:

The notion of an outdated object denotes a registry object whose database representation has been changed since it was read. This is usually caused by a different client modifying the same instance. Trying to modify an outdated object leads to the following exception:

CSAF supports automatic re-reading of outdated objects; this forces a re-read of the object from the database before applying the changes.

In general, the application must minimize the time a registry object is kept locked in the database, that is, the time during which there are ongoing modifications on it.