Dain Sundstrom wrote:
--On Monday, December 9, 2002, at 10:51 AM, David Ward wrote:Bill Burke wrote:Answer?
Because there is no way to propagate transaction and security contexts to
the spawned threads unless J2EE provided a thread creation API.
Bill
I was under the impression that transaction and security context propagation was done using java.lang.ThreadLocal - a nice way to have a variable available to all work done in a server request thread (without having to pass the same params to everyone), as long as the class holding the (ThreadLocal) variable lives in a common > ClassLoader.
Now, to address accessing it via spawned threads, wouldn't java.lang.InhertiableThreadLocal work for tx and sx propagation? Take a look at the class description in javadoc.
The real problem I see is orchestrating a single, safe commit... when?
Only one thread is allowed to be associated with a transaction at a time (it's in one of the specs), so which spawned thread gets the tx?
-dain
I understand that the spec says only one thread is allowed to be associated with a tx at a time, but I thought the discussion was centered around limitations of the spec, and what might want to be changed about it (and then, of course, how it could be done - we're programmers after all). ;)
I guess my fundamental question is, is it a transaction that has a reference to a thread (which seems pretty limited - probably for good reasons initially), or is it the thead that carries the reference to the transaction (context)? If it's the later, that's when I suggested that InheritableThreadLocal could come into service. Each spawned thread could still access the tx from the InheritableThreadLocal. If it's the prior, then I'll have learned something and retract with my tail between my legs - no problem.
David Jenks said, "The inheritablethreadlocal doesn't seem to fit with thread pooling all that well."
I would disagree with this since thread local variables could be reset before the thread is handed out to someone else.
But then he said (and I agree), "To me the question is how to provide some protection against threads interfering with each other, such as two threads accessing the same database. The jca 1.5 spec has thread pooling and transaction import features, but it prohibits 2 threads working in the same tx at the same time, presumably due to the difficulties of ensuring consistent or deterministic results should this be allowed."
- That's probably the clincher, and not an easy one to resolve.
David
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
