Dirty Design II

[Brian McCallister <mc...@forthillcompany.com>]

Okay, here are my thoughts on client-side API for the dirty broker 
stuff:

1) Expose factory for them analogous to the new OJB class.

2) Obtaining a broker obtains an instance of the PB sub-interface, 
DirtyPB (needs better name)

3) DirtyPB defines one additional method, 
DirtyPersistenceBroker#getObjectTransaction(): ObjectTransaction

4) The OT is reusable (can commit it then begin it) and the same OT is 
associated with the broker for the duration that the broker is open (if 
broker is closed and re-issued from pool, new Ot attached).

5) The OT exposes the object graph transaction stuff -- lazy inserts, 
lazy deletes, change detection, attach, detach, optimistic TX's

6) By default OT is pessimistic -- exact correlation between OT tx and 
PB tx. Calling OT#begin() will start a PB transaction.

7) The converse is not true, calling PB#beginTransaction() will *not* 
begin an OT transaction.

8) If an pessimistic OT tx is in progress, and 
broker.commitTransaction() is called, the OT tx *will* be flushed and 
committed.

9) If an optimistic OT tx is in progress, and 
broker.commitTransaction() is called, the OT tx will *not* be flushed 
or committed.

10) The optimistic status of an OT is controlled via a bean property on 
the OT, and remains as set on the OT across transaction boundaries. So 
if you say ObjectTransaction#setOptimistic(true) and then go through a 
series of object transactions, they will all be optimistic.

11) Instances retrieved by the PB will be registered with the 
associated OT if, and only if, the OT is transactional.

12) Detaching instances from the OT will cause changes to be flushed on 
the detached objects. If an optimistic TX is in progress they will be 
flushed all the way to the datastore (begin, flush, commit on the pb), 
if a pessimistic tx is in progress they will be flushed in the pb 
transactional context., but said tx won't be commited.


The basic idea here is that you can get identical behavior to the 
current PB by simply not starting an object transaction. If you want to 
get object transactions (change detection, rollback capability) you 
grab the OT and begin an object transaction. While that is in progress 
anything retrieved, or registered (transient instances can participate 
as well) with the OT will be tracked in the OT.

The OT can be kept in lockstep with the rdbms/jta transaction by 
keeping it pessimistic, or can vary independently (pure object state 
tx) by becoming optimistic. Flushing from an optimistic transaction 
will begin a pb transaction for the duration of the flush, and will 
throw an exception on optimistic failure.

There should be no overhead for operations against the PB when there is 
no object transaction in progress (ie, typical read-only operations for 
reporting etc) and when change detection is needed, only the state of 
instances loaded while the object transaction is open will be tracked 
by it.

This specifically does not provide isolation semantics. I think that 
belongs either in the cache, or in a layer between the cache and the 
broker.

-Brian



---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org