hey dejan, after thinking about the stomp ack described on the wiki page i have some points to mention. As far is i understand the behaviour of jms transacted sessions, the big advantage is the use of the message broker for delayed delivery. for me this was understood as a message broker support for delayment, incl. max delivery tries and some multiplier logic for the delayment of the redeliveries; and delayment means, it would not be send in an ordered manner but in a timed manner. i thought redelivery in the message broker is a solution which disburdens a consumer which maybe communicates with an external, sometimes broken api, from the need of dispatching this event to another layer of event handling which is executed in a different interval (like 'try it every 30 minutes'). the consumer ack is a cool feature, but the use of (somehow) transacted stomp sessions would be very interesting, too. though i have no idea how this would fit into the stomp protocol in general.
thx, jochen -- View this message in context: http://www.nabble.com/STOMP---transacted-session-tp22011259p22109132.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
