commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Hamid <>
Subject Re: [Transaction] API, GenerickLock, FileResourceManager (was Re: Transaction API, GenericLock, FileResourceManager)
Date Mon, 27 Jun 2005 14:46:21 GMT
Ah, I see!  So for instance the abstract notion of "owner" detached from thread can enable
things like locks migrating across threads.  That's very interesting.

Thanks Oliver,


Oliver Zeigermann wrote:
> On 6/27/05, Aaron Hamid <> wrote:
>>I will use Thread.currentThread() for the "owner".  I'm not clear as to the utility
of non-thread owners...what is the semantics of synchronization if the owners are not threads?
 Or is the intention that owners ultimately must be associated with unique threads?
> If something is actually blocked, it of course is the thread. But the
> thread that does something on behalf of a therad owner may change,
> e.g. when a transaction is suspended in one thread and resumed in
> another. In something like JTA you will have to tell the TM about
> this, in commons transaction you will not have to.
> Oliver
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message