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? Thanks, Antranig. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
