Re: [JBoss-dev] Transaction propagation change

[danch]

If I understand you right, you're asking to propagate transactions via JMS messages because they're not propagated via non-local EJB calls. I think that begs the question, doesn't it?

Meanwhile the conversation has gone on to (basically) asynchronous EJB (really AOP) calls.

Barlow, Dustin wrote:

Let me simplify the example to demonstrate my real point. (and hopefully
this is a better example)

In the 3.x series of JBoss, there isn't a way to have one SSB with a
transaction attribute of Required call another SSB with a transaction
attribute of Required on a second jboss instance and have both of those
beans enlist in any kind of "native" JBoss transaction. If you stay within
one instance of JBoss, you are fine, but the moment you start to really do
n-tier designs with tight transaction integration (ie XA),

tight integration implies high coupling, which implies that they ought to be co-located. If the two components are loosely coupled, then you should be able to design it in the old fashioned MOM style, where transaction propagation isn't needed.

that is when
problems arise with this NotSerializable exception.  I do know that the 3.x
series only supports local transaction, but my overall point is that I just
don't understand why a distributed transaction has not been a "native"
feature of JBoss from the beginning being that it seems to me that it would
be fundamental to n-tier designs.  I presume there is a good reason for
this.  I just don't know/see what that reason would be.

Distributed TX is more expensive - the JBoss TM is intended (currently) to be light-weight and quick rather than XA complete.

If you have persistent JMS queues, then I would probably agree that having a
distributed global transaction involved when asychronous transports are
involved may not be best practice.  However, if a non-persistent JMS queue
is used (and i don't know why anyone wouldn't use persistence), then I can
see having a distributed transaction as very beneficial to the integrity of
a single unit of work.

Except that you're using a very heavyweight, MOM-style API when what you wanted was just correct transaction behavior.




-------------------------------------------------------
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