ObjectExtender User's Guide and Reference

Transaction framework

Operations on persistent objects have transaction semantics similar to the data stores in which they persist. The transaction framework provides that all operations within a transaction are either committed or rolled back together so that a consistency is maintained within the OO environment. Transactions are introduced into the persistence binding through a set of synchronization and collision management schemes.

Synchronization schemes

Synchronization between application and data memory spaces is achieved by various synchronization shemes. These schemes define when modified objects in the application memory are sent to the database and when objects are refreshed in the database. For example, a deferred write scheme would imply that modified objects are first recorded within a transaction, then, when the transaction is committed, the modified objects are automatically written to the database all at once.

Collision management schemes

Collision management schemes provide different approaches according to the different types of transactions defined. Transactions with a high penalty for failure, for example, could have a pessimistic collision prevention scheme, whereas transactions with a low penalty for failure, that is, it is worth the risk of failure to gain the efficiency, could have an optimistic collision detection scheme.

A flexible collision management scheme is based on the properties of the transaction, the domain class, and the data store. For example, within a transaction there may be participating objects that are not candidates for collision. When the transaction directs its participants to lock their resources, the non-collision candidates will do nothing since they have no resources that require locking.

The net effect of collision management strategies depend entirely on what the underlying data store supports.


[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]