ObjectExtender User's Guide and Reference

Programming model overview

ObjectExtender offers a single-level store model. Tracking which objects are created, deleted or modified in a transaction is done by ObjectExtender. Thus, at the highest level, the program flow is:

  1. Start a transaction.
  2. Create, Retrieve, Update and Delete objects, Navigate, Add and Remove from relationships.
  3. Commit or roll back the transaction.

ObjectExtender offers support for both optimistic (non-locking) and pessimistic (locking) policies for managing transactions. In the case of optimistic management, ObjectExtender defers all locking and updates on the backend store to the commit phase of the ObjectExtender transaction. This means that, at least in the case of optimistic transaction management, it is feasible to have long-running ObjectExtender transactions that have good concurrency characteristics on the backing store, because they do not consume locks or other significant backend resources. In this case, the programming model looks more like:

  1. Start a transaction.
  2. Repeatedly interact with a user and Create, Retrieve, Update and Delete objects, Navigate, Add and Remove from relationships.
  3. Commit the transaction.

ObjectExtender supports nested transactions, so a more complete model would be:

  1. Repeatedly interact with a user and Retrieve objects, Navigate relationships.
  2. Start a transaction, t1.
  3. Repeatedly interact with a user and Create, Retrieve, Update and Delete objects, Navigate, Add and Remove from relationships.
  4. Create a nested transaction, t2.
  5. Repeatedly interact with a user and Create, Retrieve, Update and Delete objects, Navigate, Add and Remove from relationships.
  6. Commit or roll back the nested transaction t2.
  7. Repeatedly interact with a user and Create, Retrieve, Update and Delete objects, Navigate, Add and Remove from relationships.
  8. Commit the top-level transaction t1.
  9. Repeatedly interact with a user and Retrieve objects, Navigate relationships.

There is no requirement that a transaction complete before a thread creates a new sibling transaction. For example, a thread may start a transaction, modify some objects, suspend the transaction and create another, modify more objects, resume and commit the first transaction and so on. There is also no requirement that nested transaction complete before its parent resumes. Within a transaction, modifications made in a parent transaction are visible, but modifications made in uncommitted sibling or child transactions are not.

ObjectExtender also supports independent Transactions executing simultaneously on separate threads, so the above program flows can be running simultaneously on multiple threads of execution within the same Smalltalk program. Nested transactions must always run on the same thread as their parent.


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