commons-user mailing list archives

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

This is possible when doing read requests outside of a transaction using 

public InputStream readResource(Object resourceId) throws

Reads and writes inside of another transaction would be disallowed,
though. It is important to disallow reads in other transactions as
otherwise various spurious and unwanted effects like e.g. lost updates
might occur...

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

I see, this is the usual way of doing this - 1:1 mappings of
transactions to threads. The JTS does this as well and maybe I should
have done this with the transactional file system?! But I guess a
layer based upon it as you described might be sufficient.

How does you nestted transaction wrapper look like? How does it work?

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

Yes, exactly, sorry for making this for complicated than necessary.

Looking forward to see more of your work! May I ask what kind of
application you are building?


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

View raw message