commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antranig Basman <>
Subject [transaction] Locking
Date Thu, 11 Nov 2004 18:16:53 GMT
Oliver Zeigermann wrote:
> > Another question - I'm looking over the locking strategy for FRM
> > and am keen that I can ensure it blocks rather than throwing
> Yes, serializability (complicated word, hope the spelling is right) is
> guaranteed by locks. There are four lock level
> 0: none
> 1: request wide read outside of transactions
> 2: transaction wide read (shared)
> 3: transaction wide write (exclusive)
> 4: commit lock that prohibits all other locks on resources being committed

Thanks - could I just confim my understanding of this with you?
In my application some files store indexes of other resources - say
that transactions T1, T2 are attempting to add to this index 
concurrently. Each reads the resource before it writes it - is it
correct that their lock level 2 they take out on read is 
insufficient to protect against lost data once they try to write
back their updated versions of the index?
What I would like is that any read within a transaction prevents
any other read of this resource within any other transaction - 
I presume I will need to ensure this manually with a call to
lockResource(resourceId, txId, false)
before each transaction issues its read?
Or is even a lock level 3 not sufficient to cause reads 
within other transactions to block?
Essentially I would like to take out a lock of a type that
prevents reads by any other threads having this same type of lock,
but allows other reads to continue. What is the type of this lock? :P

> However, if a lock can not be acquired in the specified time the lock
> methods will throw exceptions. Currently, the file system can not tell
> a livelock from a deadlock. Both will just throw an exception...
> > whenever possible. I notice that in lockResource() there is a call
> > to
> > assureNotMarkedForRollback(context);
> > which, by my best understanding, will throw if a prepareTransaction
> > has failed on the resource. Could you explain why this is necessary?
> Yes, or if it has explicitely been marked for roll back by method
> markTransactionForRollback. The reason is to tell the user not to make
> any modifications to a transaction that will eventually fail anyway.
> However, you are right, this is not mandatory for correctness...
> > To be sure, if one transaction has failed on modifying a resource,
> > it is quite likely that another will, and the time window for
> > observing this effect is only that between a prepare fail and an
> > exception handler being located for a rollback, but I'd like to
> > understand the reasoning behind it if I can.
> Do not quite understand this. Could you explain a bit more, please?

I think the only point of confusion may be whether we are talking
about mark for rollback by a transaction for *this* thread or
by any other threads. If *this* thread is in the middle of a rollback
then it is quite right that a lock should throw, since this 
almost certainly represents a programming error... but then if the
author has screwed up exception handling to this extent they
probably will not listen to a further one :P On the other hand
failing a lock because *another* thread is rolling back seems
rather severe - I presume it is the former we are talking about?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message