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

[Michael W. <mi...@ra...>]

Hi,

On Sun, 24 Mar 2002, Georg Schneider wrote:
> from the database that are old, before borker.comitTransaction actually
> writes them to the database

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

> > 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 ...

Best wishes, Mike

-- 
Don't feed.                                               DI Michael Wildpaner
Don't provoke.                                                   Ph.D. Student
Don't enter the cage.