Dustin, I am sorry I went on a tangent, it is just a pet peeve of mine for the longest time (and I still have to hear about OLE, who likes these discussions ;).
> 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. Colocate! colocate! colocate! if you have a REAL reason for not colocate let's hear it. That has to do with the lack of distributed TM. Period. > 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), By design and choice yes. > 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. That is easy. SPEED. Distributed transaction are pricey and difficult. By choice we did "fastTM" as an InVM implementation. Typical case of 90/10. Most applications actually use only invm stuff and so having an implemetnation that serializes stuff back and forth isn't worth it. Right now FastTM is REALLY FAST, so that the overhead of synchronization is NIL (dozen or so native java method calls). It is one of these things where we said "you really need DTM, write it or use tyrex". Turns out Tyrex was a fake with critical methods throwing NotImplementException. But clearly we didn't BASE the design on distribution. That being said 2 point: 1- even the EJB spec writers do research on invm tm. 2- we are writing parts of a real DTM. Please help. > 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. That is what I contest. Why ? So what if it is persistent/async? theoretically speaking what is the limitation here? 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
