> > But to do this you need a way to create a thread in a > > "transaction-friendly" way i.e. if you simply create a new > > thread (t = new Thread), then new correct transactional > > context is associated with this newly started thread. Correct? > > inheritableThreadLocal (or something like that)
Yes, but I meant that there is no standard way to do that i.e. what is missing is a way, in any app server or transactional-aware software, to use an API and say "I want a thread that participates in my current transaction". For many app server, inheritableThreadLocal may be enough, for other not. Furthermore, by using ITL you bypass the thread pool. I guess it simply comes down to the fact that since the beginning we hear in specs: "threads are bad, bouh!" , thus it has never been standardized and instead we have to use 3000 lines of JMS + MDB to simulate async behaviour in containers. I guess this is the whole point: current JMS transactional behaviour is fine as long as what you want is *really* to decouple the producer from the consumer, but when what you want is just "transactional multithreaded", then it is no more (and by far) a good solution because you end up using JMS+MDB for *nothing* ------------------------------------------------------- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
