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:
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:
ObjectExtender supports nested transactions, so a more complete model would be:
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.