Let me first give a brief introduction of the business scenario -
I am using JMS Queues and I have a Java application which listens on this queue constantly. Wheneever, there is a message on this queue, it is picked by this Java application and a stored procedure is called internally and the data from the message is stored in the database tables.In an ideal scenario,the message would be succesfully parsed and the data would be succesfully commited into the database and then the Queue would be committed.
The problem with this approach Imagine now, that due to some reasons, the database commit was succesful but the Queue commit fails. In this scenario, the same message would be picked by the java application listening on the Queue and all the cycle repeats again which is not desirable at all.
So, I am looking for a solution wherein either both the database and the Queue commit or both Rollback.
Thanks in advance !!!
posted 8 years ago
Why not,as your first step when receiving a message, check whether a duplicate exists in the database; if so, disregard the incoming message.
You should be able to do a simple select based on the criteria of the message; I assume you're using some form of compound key based on message properties.
This is probably simpler than trying to get a transactional rollback system working.
Failing that, I believe there are several distributed transactional systems for JMS. What JMS Server are you using?
McFinnigan? Never heard of him. Nobody here but us chickens...<br /> <br />SCJP for Java 1.4<br />SCJD for Java 5.0