> 1. multiple threads in one tx. This is doable technically and may > produce determinate results if all threads access only different > resource managers. If any access the same resource manager, you will > easily get indeterminate results (e.g. one thread adds 2, the other > thread mulitplies by 10, you start with 1, you can get 30 or 12 > depending on order). This is not messaging in any sense I > can think of.
Order within a Transaction for correctness is not a design goal of transaction. Ordering of operations is a programmatic problem. I wouldn't ruse transactions to do that. I use transactions ON THE WEB to coordinate components. When there are many threads doing work a way to synchronize the work is with the 'commit' notifications from the 'orchestrator'. Ordering is an orthogonal issue. > I'm not sure the "messaging" part of this adds anything. We could do > the same thing with just threads much more easily. If you > think doing > an optimization specifically with messaging like this adds something > useful please provide a concrete example. My point is that the transactional scope ends at the message layer (besides the enrollment in sending and receiving) and I don't see a fundamental reason for it. Why can't I think of my "application critical unit" as containing messages? essentially J2EE restricts me to designing critical sections WITHOUT messaging. For me the transaction (we are way passed the "DB" notion of it) is a higher level construct that visually isolates components and flows of the application under TX scope so their effect can be rolledback/synchronized. It is also a SIMPLER notion. I don't grock why a message or async call in general shouldn't be capable of propagating TPC. Concrete example. Buy book == debit credit card + send book. Both sub operations are triggered by MDB or message in general. TM knows there are 2 component to the transaction, does 2phi dance when both are registered. The fact that there is a message in the middle is it relevant? You ask if it is worth doing. I say I am in 'theory land' so probably not. The designs of the TM need to change a bit, meaning for example that the application needs to delegate synchronizatio to the TM and say "there should be 2 components to this application (2 synchronizations registered) if not then you can rollback on timeout. But as soon as both are registered and I tell commit go ahead". 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
