My answers/comments are inline: > 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 ;).
No need to apologize at all. I think it's an interesting topic as well. Plus you're the "boss" so :) > > > 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. I am arguing for co-locating, so i take it that your "challenge" for reasons *not* to co-locate is not directed at me. Load balancing is one reason *for* co-locating. Lets say I want to run multiple instances of JBoss on separate iron(s) for performance reasons. One instance that simply does all the persistence for my application with synchronous session facades (or perhaps async MDB based dispatchers) in front of entity beans. Then I have another node that does all the business logic/presentation logic in SSB's. Then maybe a third for the front end (jsp's, servlets, ssb's etc). How would I inforce ACID semantics in this setup if local only transactions are the only option? > 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. I completely agree in terms of the speed aspect, however, shouldn't JBoss still have the option/ability of doing distributed transactions being that it is fundamental to a ACID n-tier based system? How are transactions handled today with clustering? If a clustered node goes down, can JBoss seemlessly pick up the pieces and move forward with a transaction or a separate node, or does it just bail out and rollback the entire thing? The major rub is that I can't even make a ejb to ejb call between two different jboss instances because it is trying to push the transaction context across the nodes, when the infrastructure doesn't support it (even if I have a transaction attribute of NEVER on both ejbs). I think this is exactly what Scott was addressing in his original post, that at a bare minium, we should have the ability to say, we don't want and can't have the transaction context pushed to the node, so don't even try. Of course this does opens up other issues as far as other beans involved in the container transaction and how they would be notified if the remote call fails. I presume this would have to be handled with tradition exception handling in the bean that actually makes the call to the remote node and it's job would be to mark the container transaction. Another scenario is a MDB deployed in one instance that is using a custom remote DestinationManager pointing to a JMS queue on a second JBoss instance (which currently doesn't work in 3.x .. but i'll leave that for another thread). How is the transaction handled in that scenario? If you say, just put the MDB on the other instance that houses the JMS queue and move to a push model instead of pull, then the problem I described above comes into play. The MDB tries to push it's transaction context to the second node, and fails. So the only way to do it is for the MDB to be BMT which means I now don't have the ability to use the message retry part of JMS. I have to write the code that handles failures, instead of letting the container do what it was designed to do. > > 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. I've read posts from Jencks and co. and it appears that a DTM is in the works for 4.x. So maybe this whole topic is a mute point. But, it could be (possibly) another year or more before 4.x is ready for production use as well, so that is why i originally asked if there was the ability to port this new feature to the 3.x series. > > > 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? I think the argument is that because you have persistence you are guaranteed message delivery even if the node dies. So once a message is successfully posted to the queue, stack returns to the caller (ie async) the "transaction" with the queue is technically done where the caller is concerned. With persistence, if the instance craters out before the message is succesfully consumed, then you should still have the message persisted and it would be picked back up and redispatched when the instance is brought back up thus protecting the original "intent" of the original poster's transaction. The originating caller can then be notified later on (if needed) once the JMS based message is consumed and processed successfully by, for example, posting back to a JMS queue on the caller's instance. Basically a workflow style system. Dustin ------------------------------------------------------- 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
