[jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1826) Removing a reference and deleting a message in DB should be wrapped in a single transaction in JDBCPersistenceManager

[Tim Fox (JIRA)]

    [ https://jira.jboss.org/browse/JBMESSAGING-1826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12560541#action_12560541 ] 

Tim Fox commented on JBMESSAGING-1826:
--------------------------------------

Howard, are you looking at this code:

 // No tx so we remove the reference directly from the db

         new RemoveReferenceRunner().executeWithRetry();

         deleteMessage(ref.getMessage().getMessageID());

?

If so, the comment says it all. This code is only executed when there is no transaction present. When there is a transaction, the other block is executed which does use a single tx.

> Removing a reference and deleting a message in DB should be wrapped in a single transaction in JDBCPersistenceManager 
> ----------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1826
>                 URL: https://jira.jboss.org/browse/JBMESSAGING-1826
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core Persistence
>    Affects Versions: 1.4.0.SP3.CP10, 1.4.7.GA
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP11, 1.4.8.GA
>
>
> In JDBCPersistenceManager, when a message is delivered and completed, the message is removed from DB. It includes two deletes in the DB - the reference in JBM_MSG_REF and the message in JBM_MSG. The two deletes are currently done in two separate local transactions as in removeReference() method:
> ...
>          new RemoveReferenceRunner().executeWithRetry();
>          deleteMessage(ref.getMessage().getMessageID());
> ...
> If a server crashes between the two operations, it will leave the tables in an inconsistent state, i.e. ref removed but the message still there. This may result in message stuck, as in this case:
> 1. A server is crashing when a client_ack comes in, the clienk_ack will cause the message to be cleared from the server. If the client_ack processing goes as far as that the removing of reference succeeds but failed to delete the message due to the crashing, the message is left in JBM_MSG table but the corresponding entry in JBM_MSG_REF is gone.
> 2. Eventually the jms client will get ack failure exception. It then expects the messages to be re-delivered after server start-up. But that will never happen. When the server starts up it loads references in JBM_MSG_REF for delivery, but this message's ref is gone.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira