Exactly. But, as I said, there are other concepts (e.g. in JTA) that work as well and sometimes even better.
Cheers Oliver On 6/27/05, Aaron Hamid <[EMAIL PROTECTED]> wrote: > 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
