AW: [OJB-developers] Serious threading/lock problem

[Mahler T. <tho...@it...>]

Hi Michael,

> 
> Persistence "borker" ... most beautiful Freudian slip in a 
> long time ;-)

Persistence is futile -- we are bork :-)

> 
> > > It won't be difficult to implement such a mechanism.
> > > But ODMG wants the implemtor to throw exceptions if Locking fails.
> > > We simply stick to the rules here.
> > 
> > I didn't bring the ODMG standard with me, but are you
> > sure, that having to wait for a lock constitutes a failure 
> to obtain a
> > lock (as opposed to let's say a timeout, where a 
> LockNotGrantedException
> > would make sense to me).
> 
> From "The Object Data Standard: ODMG 3.0",
> 2.9: Locking and Concurrency Control
> 
> 	"The ODMG Object Model supports traditional pessimistic
> 	 concurrency control as its default policy, but does 
> not preclude
> 	 an ODMS from supporting a wider range of concurrency control
> 	 policies."
> 
> and the ODMG Java Binding says in 7.1.4.10: Exception Handling:
> 
> 	"LockNotGrantedException ...
> 
> 	 Thrown if a lock could not be granted. (Note that time-outs and
> 	 deadlock detection are implementation-defined.)"
> 
> Combining these statements with a definition of pessimistic 
> locking, e.g.
> <http://www.ambysoft.com/ooGlossary.pdf>, I am led to 
> conclude that the
> implementation is free to immediately signal an error _or_ deferr the
> locking decision to a later point, given that other 
> concurrency guarantees
> are not violated. Timeouts and deadlock detection are even explicitly
> mentioned ...
> 

The ODMG spec is not precise in many respects. 
Implementors have to fill many undefined or unclear spots while implementing
the API.
It is not always easy to grasp the general intention of the ODMG designers.
For instance some time ago we had an in depth discussion about implicit lock
acquisition. (Please refer to the ODMG mailinglist archive).

You came to a conclusion about ODMG Locking behaviour by referring to
external sources (Amby's OO Glossary).
IMHO your conclusion is plausible.
But does it fit to the general idea of the ODMG designers? I really don't
know!

There is a method org.odmg.Transaction.tryLock(Object obj, int lockmode):
    /**
     * Upgrade the lock on the given object to the given lock mode.
     * Method <code>tryLock</code> is the same as <code>lock</code> except
it returns
     * a boolean indicating whether the lock was granted instead of
generating an exception.
     * @param	obj	The object to acquire a lock on.
     * @param	lockMode	The lock mode to acquire. The lock modes are
<code>READ</code>,
     * <code>UPGRADE</code>, and <code>WRITE</code>.
     * @return	True if the lock has been acquired, otherwise false.
     */
    public boolean tryLock(Object obj, int lockMode);

It will be very easy for ODMG users to build their specific timeout
semantics with this methods.
That's why I believe it is OK to immediately throw an exception in
.lock(...).
There are also other ODMG implemtations (e.g. for the Objectivity ODBMS)
that work like this.

But as always with OJB: If you or others volunteer to implement a timeout
scheme for the OJB ODMG locks I'll be most grateful and promise to integrate
it into our codebase !

cu,

Thomas