commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antranig Basman <>
Subject Re: [transaction] Locking
Date Fri, 12 Nov 2004 17:44:50 GMT
Oliver Zeigermann wrote:
> 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)...

Yes - to be more clear, in my application I do not want to exclude
non-writing readers from reading in this case. I only want to exclude
writing ones - from what you are saying I cannot achieve these 
semantics with the current LockManager implementation?

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

Yes - I actually have a TransactionThreadMap for this purpose and 
at my higher API level transaction IDs do not appear as method
arguments. Perhaps I might contribute it so you can save a 
few (one?) methods in your FileResourceManager? :P
I have also made a "NestedTransactionWrapper" that uses this class
to provide nested transaction semantics to users. Trouble is these
have dependency on my "UniversalRuntimeException"
scheme for avoidance of checked exceptions wherever possible...

> > 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 think our terminology agrees. Since transactions should have the
impression that no other transactions are in force, what you are 
telling me implicitly is that the answer to my question is that
assureLock() will only throw if *this* thread is in a transaction
that is rolling back, ignoring the state of any others. Could you
just briefly confirm this? :P


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

View raw message