> 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.
well what you want is a language level construct a la corba where a method can be said "ONE-WAY". In fact we could TOTALLY do that on the new AOP framework. If you define with an xdoclet tag that a given method is "@jboss:one-way" then we put an interceptor that takes fresh thread and returns immediately. Me likes. The question of how we do it is secondary, either we go purely threadLocal (a hack) or we rely on the "invocation' which should contain most of the data, Adrian pointed out in the forums that we need to do some more leg work on putting data in the invocation, but in any case. Associating the data with the thread one way or the other is easy. > 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* right, it is a good point. The transactional part is lost. A simpler way is that there is NO propagation of TX context across async today and we could somewhat easily do it. DTM is still missing from the picture :) marcf ------------------------------------------------------- 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
