Please don't take offense here, but you seem to be heading in a couple of directions where, based on my experience, I think you'll hit some problems. Apologies in advance if I've misunderstood.
Barlow, Dustin wrote:
I think you're arguing against colocating here, unless I'm missunderstanding dramatically.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 runtwo points:
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.
1. separating things out this way is very likely to hurt your performance. If you want performance, you should have the whole stack in the same process. If you want scalability, load-balance the whole application vertically, not horizontally. Yeah that's not what leaps to mind when they (we, speaking as one of they) say 'N-Tier', but it's what works.
2. ("async base MDB dispatchers") You're not proposing doing a request/reply to an MDB, are you? That's taking an asynch. transport (NOTHING TO DO WITH TRANSACTIONS HERE!) and simulating a synchronous call over it. That tends to perform badly, you'll have some complex code to manage it, and I've found it to generally be a bad idea.
The more typical need for distributed TX involves one application (A) that needs to make a request to another application (B), where A needs to know the result of the request (making synchronous the prefered invocation style) and a roll-back in either A or B needs to roll-back the both thing.
The only time it makes sense to use JMS/MOM is when the requestor (A in my meta-example) doesn't really care what happens, AND where a rollback in B won't matter to A. Note that if A rolls back, the message will never be delivered. This is basically a case of A wanting to say "Oh, if anybody cares, this happened." Extreme decoupling. The error handling on B's side tends to get a little hairy in these cases: it may need to intelligently recover from some errors, others can be retried at a later point, and for some errors it will wind up deffering to certain wet, grey, bio-electrical analog computers for resolution.
Oh, the other time MOM makes sense is when one or more applications need to be integrated and they're entirely ignorant not only of one another, but of distributed transactions, Java, and the modern world in general. But hey, it keeps me busy!
<snip!>
The transaction is between the queue and the MDB - the ack for the message should be sent to the queue iff the MDB's transaction commits. The transaction started for the MDB's processing of the message is the only transaction in this scenario. What's the question, other than 'this doesn't work in 3.x.' It should.
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?
-danch
-------------------------------------------------------
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
