Barlow, Dustin wrote:
because if you care about the transaction, JMS is the wrong tool. There's no theoretical limitation, but if what you want to to execute an asynchrounous task in the same transaction, why would you go through all of the JMS crap that's designed for a 'fire and profess apathy' sort of exchange. You want a tightly coupled transaction: why would you use an API that assumes the loosest of all possible couplings?
That is what I contest. Why ? So what if it is persistent/async?
theoretically speaking what is the limitation here?
Answer: only because marcf hadn't written the one-way spec yet! ;^})
Yes! If that's not the behavior you want, you shouldn't be using persistent messaging.
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.
exactly. that's what MOM systems are for.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.
-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
