commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Hamid <ar...@cornell.edu>
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,

Aaron

Oliver Zeigermann wrote:
> On 6/27/05, Aaron Hamid <arh14@cornell.edu> 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: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message