Simon Brown enters the hell that is J2EE fineprint: The reason that we discovered this is because we were trying to figure out the best way to implement logic like, "sorry, not quite ready to process this message yet". - Simon Brown That would be 503 Service unavailable in HTTP. I love HTTP. I came across this problem recently in a different context to Simons' transaction case - mine was MDB throwing an exception to the container and the container continously resending the message. The simplest answer seemed to be to have retry/dead-letter queues - otherwise you end up tied into someone's JMS provider via configuration lock-in. Sometimes you don't want to have a message retried after a number of efforts; sometimes it has to run within a certain time; sometimes there's no point in resending (like invalid XML in a text message). Having retry and dead-letter queues is more work, but it is somewhat portable. Sometimes what JMS provides is too low-level to represent the application problem - there's a world of difference between a transaction and an order fulfilment. And that's why I love HTTP (and Internet protocols in general) over APIs - quite often they have exactly the semantics your application needs....
Previous Topic
