On Thu, 11 Nov 2004 18:16:53 +0000, Antranig Basman <[EMAIL PROTECTED]> wrote: > 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
Sorry for causing confusion, these lock levels are just internal ones. For you the public boolean lockResource(Object resourceId, Object txId, boolean shared) throws ResourceManagerException method is the one to use. It will be called implicitely along with all read/write requests as well. So, if you want an exclusive lock, just set shared to false and there you go. This will be set to exclusive as soon as a transaction starts to write as well. However, if you know even before reading that you will finally write, it is a very good idea to get an exclusive lock right at the beginning of a transaction. This decreases the likelyhood of a deadlock (to almost zero)... > > 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 you have a threaded application I highly recommend to associate a thread to exactly one transaction. Just use the thread itself as the transaction id. If so, there will be at most one thread that can mark a transaction for rollback. > 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? Hmmm, I am afraid I still do not understand you completely. Usually, the idea of using transactions includes that each transaction should have the "impression" that there are no other transactions... Maybe we do not use the same terminology: What is your understanding of a transaction and a rollback of a transaction and what is your idea of locking a resouce? I am pretty sure once we get definitions aligned, we can settle this quickly... Oliver --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
