> Dustin,
> 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.
I never take offense to constructive criticisms/comments, I learn from them,
so no apologies needed here. My original example didn't quite clearly
convey the scenario I was attempting to explain. I was not wanting
transaction propogation via the JMS message.
> I think you're arguing against colocating here, unless I'm
> missunderstanding dramatically.
Sorry, I was using the word "co-locating" in the opposite sense, ie separate
jboss instances.
>> two points:
> 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.
I understand and agree with you. However, there are times when one must
integrate horizontally with other systems that may not live on the same iron
and run under the same VM. Jboss cannot "natively" do DTM (JTS), even w/o
JMS in the picture.
> 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.
No, that's not what I am suggesting by the term "async based MDB
dispatchers". I mean "dispatch" in the sense that you have n number MDBs
reading from a JMS queue and "dispatching" to n number of worker SSB's. The
MDB basically plays traffic cop and invokes the appropriate SSB based upon
parsing the JMS message headers.
>
> 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.
Agreed and again, JBoss, in it's current 3.x state, cannot natively do this
across JBoss instances.
>
> 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.
Agreed. (and very funny) :)
> 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.
If you have a remote MDB on one JBoss node that wants to listen for messages
off a second jboss node that houses the JMS queues, how is the transaction
handled there if jboss doesn't propogate transaction context between the
instance housing the MDB and the instance housing the queues? JBoss does
provide a DestinationManager which can be configured with a RemoteURL
property, even though I have been unable to get it to work with a MDB
(that's the it doesn't work and it should part).
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
