[OJB-developers] Re: OJB-ODMG does[n't] support implicit locking

[Doug C. <de...@fl...>]

TM> Here is my argument why OJB still meets the requirements:

TM> During tx commit OJB automatically upgrades Locks for objects that only
TM> have a READ lock. So we obtain WRITE locks implicitely for modified
TM> objects. ODMG does not specify at which point in time the WRITE lock is
TM> to be acquired!  ;-)

I might buy this if
a) the READ locks were obtained implicitly, and
b) the isolation mode is read-uncommitted

Neither of these is true in my example.

TM> One of the next things we implement is optimistic locking (similar to
TM> the TOPLink approach).

Yes, this would be nice; a version number or timestamp would be needed
on each object to see if the current version on disk matches the
version modified by the transaction.

TM> If an application uses optimistic locking your argument is not longer
TM> valid, as collision-detection is delayed until RDBMS access during tx
TM> commit.

The problem remains that transaction isolation is violated since an
object can be modified by multiple transactions since there is only
one version in the cache. JDO fixes this by having many copies of the
same object in memory, one per writer. This breaks java object
identity, so they invented "JDO identity."

TM> So I cannot see why OJB should not be compliant to the implicit locking
TM> feature!

As long as there are versions/timestamps and many copies of the
same object in memory, one per writer.

TM> There are also some "lazy" implementors (e.g. Objectivity) that require
TM> the user to place locking code into getter and setter methods.

TM> I think this is a valid approach, as the intrusion into user code is
TM> minimal.

It is worth considering.

TM> Currently I favour the following implementation strategy for OJB-JDO:
TM> Reuse (or make a clearroom rewrite) of those aspects of SUNs JDO
TM> Reference Implementation (RI), that are related to Lifecycle,
TM> Codeenhancement etc.

The current RI enhancer generates source code, and is non-compliant.

TM> And simply write a com.sun.jdori.StoreManager implementation that
TM> parallels the com.sun.jdori.fostore.FOStoreStoreManager but uses a OJB
TM> PersistenceBroker to perform persistence operations.

I suspect you may also want to consider:
- using some of the current odmg locking stuff
- using some of the current odmg ObjectEnvelope stuff
- making ojb.broker's repository.xml syntax more compatible with jdo
  (or adding an alternate syntax there)

Regards,

e