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

[JBoss JIRA] (JBJCA-825)...

[JBoss JIRA] (AS7-4875) Need...

Yong Hao Gao (JIRA)

Sunday, 31 October 2010 Sun, 31 Oct '10

9:26 p.m.

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.7.GA, 1.4.0.SP3.CP10 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

Show replies by date

Yong Hao Gao (JIRA)

Sunday, 31 October Sun, 31 Oct

10:23 p.m.

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

[ https://jira.jboss.org/browse/JBMESSAGING-1826?page=com.atlassian.jira.pl... ] Yong Hao Gao commented on JBMESSAGING-1826: ------------------------------------------- Note: This only solves the inconsistence state in DB. The ack may still fail during the crashing after both message ref and message been deleted.

...

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

Tim Fox (JIRA)

Monday, 1 November Mon, 1 Nov

3:40 a.m.

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

[ https://jira.jboss.org/browse/JBMESSAGING-1826?page=com.atlassian.jira.pl... ] 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.

Yong Hao Gao (JIRA)

7:17 a.m.

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

[ https://jira.jboss.org/browse/JBMESSAGING-1826?page=com.atlassian.jira.pl... ] Yong Hao Gao commented on JBMESSAGING-1826: ------------------------------------------- Hi Tim, Yes I'm referring to this no tx code. The RemoveReferenceRunner().executeWithRetry() is doing the removing of reference in JBM_MSG_REF table. It does it using a local DB transaction. The deleteMessage(ref.getMessage().getMessageID()) uses another DB transaction to do the deleting of message in JBM_MSG table. If JBM server crashes in between the two statements, it will leave in DB an inconsistent state, where entry in JBM_MSG_REF is gone but the related entry in JBM_MSG still there.

...

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.

Tim Fox (JIRA)

7:33 a.m.

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

[ https://jira.jboss.org/browse/JBMESSAGING-1826?page=com.atlassian.jira.pl... ] Tim Fox commented on JBMESSAGING-1826: -------------------------------------- Ok, so this is a more of a "nice to have" and the problem doesn't affect transaction intregrity since if the user was using a tx then this issue cannot occur.

...

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.

Yong Hao Gao (JIRA)

Wednesday, 3 November Wed, 3 Nov

7:38 a.m.

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

[ https://jira.jboss.org/browse/JBMESSAGING-1826?page=com.atlassian.jira.pl... ] Yong Hao Gao updated JBMESSAGING-1826: -------------------------------------- Fix Version/s: 1.4.0.SP3.CP12 (was: 1.4.0.SP3.CP11)

...

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.CP12, 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.

Yong Hao Gao (JIRA)

Friday, 29 April Fri, 29 Apr

8:01 a.m.

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

[ https://issues.jboss.org/browse/JBMESSAGING-1826?page=com.atlassian.jira.... ] Yong Hao Gao updated JBMESSAGING-1826: -------------------------------------- Fix Version/s: 1.4.0.SP3.CP13 (was: 1.4.0.SP3.CP12)

...

Removing a reference and deleting a message in DB should be wrapped in a single transaction in JDBCPersistenceManager ---------------------------------------------------------------------------------------------------------------------- Key: JBMESSAGING-1826 URL: https://issues.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.CP13, 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. For more information on JIRA, see: http://www.atlassian.com/software/jira

Yong Hao Gao (JIRA)

9:19 a.m.

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

[ https://issues.jboss.org/browse/JBMESSAGING-1826?page=com.atlassian.jira.... ] Yong Hao Gao updated JBMESSAGING-1826: -------------------------------------- Fix Version/s: 1.4.8.SP1 (was: 1.4.8.GA)

...

Removing a reference and deleting a message in DB should be wrapped in a single transaction in JDBCPersistenceManager ---------------------------------------------------------------------------------------------------------------------- Key: JBMESSAGING-1826 URL: https://issues.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.CP13, 1.4.8.SP1 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. For more information on JIRA, see: http://www.atlassian.com/software/jira

Yong Hao Gao (JIRA)

Tuesday, 21 June Tue, 21 Jun

7:52 p.m.

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

...

Removing a reference and deleting a message in DB should be wrapped in a single transaction in JDBCPersistenceManager ---------------------------------------------------------------------------------------------------------------------- Key: JBMESSAGING-1826 URL: https://issues.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.CP13, 1.4.8.SP2 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. For more information on JIRA, see: http://www.atlassian.com/software/jira

Yong Hao Gao (JIRA)

11:33 p.m.

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

...

Removing a reference and deleting a message in DB should be wrapped in a single transaction in JDBCPersistenceManager ---------------------------------------------------------------------------------------------------------------------- Key: JBMESSAGING-1826 URL: https://issues.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.CP14, 1.4.8.SP2 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. For more information on JIRA, see: http://www.atlassian.com/software/jira

Yong Hao Gao (JIRA)

Tuesday, 19 July Tue, 19 Jul

9:54 p.m.

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

...

Removing a reference and deleting a message in DB should be wrapped in a single transaction in JDBCPersistenceManager ---------------------------------------------------------------------------------------------------------------------- Key: JBMESSAGING-1826 URL: https://issues.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.CP15, 1.4.8.SP2 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. For more information on JIRA, see: http://www.atlassian.com/software/jira

Yong Hao Gao (JIRA)

Thursday, 21 July Thu, 21 Jul

12:57 a.m.

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

...

Removing a reference and deleting a message in DB should be wrapped in a single transaction in JDBCPersistenceManager ---------------------------------------------------------------------------------------------------------------------- Key: JBMESSAGING-1826 URL: https://issues.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.CP15, 1.4.8.SP3 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. For more information on JIRA, see: http://www.atlassian.com/software/jira

Yong Hao Gao (JIRA)

Thursday, 8 September Thu, 8 Sep

10:33 p.m.

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

...

Removing a reference and deleting a message in DB should be wrapped in a single transaction in JDBCPersistenceManager ---------------------------------------------------------------------------------------------------------------------- Key: JBMESSAGING-1826 URL: https://issues.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.CP15, 1.4.8.SP4 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. For more information on JIRA, see: http://www.atlassian.com/software/jira

Yong Hao Gao (Updated) (JIRA)

Tuesday, 25 October Tue, 25 Oct

10:44 p.m.

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

...

Removing a reference and deleting a message in DB should be wrapped in a single transaction in JDBCPersistenceManager ---------------------------------------------------------------------------------------------------------------------- Key: JBMESSAGING-1826 URL: https://issues.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.CP15, 1.4.8.SP5 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, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

Yong Hao Gao (Updated) (JIRA)

Thursday, 27 October Thu, 27 Oct

8:21 a.m.

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

...

Removing a reference and deleting a message in DB should be wrapped in a single transaction in JDBCPersistenceManager ---------------------------------------------------------------------------------------------------------------------- Key: JBMESSAGING-1826 URL: https://issues.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.CP15, 1.4.8.SP6 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.

Yong Hao Gao (Updated) (JIRA)

Wednesday, 4 January Wed, 4 Jan

9:25 p.m.

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

...

Removing a reference and deleting a message in DB should be wrapped in a single transaction in JDBCPersistenceManager ---------------------------------------------------------------------------------------------------------------------- Key: JBMESSAGING-1826 URL: https://issues.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.CP15, 1.4.8.SP7 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.

Yong Hao Gao (JIRA)

Sunday, 15 April Sun, 15 Apr

11:07 p.m.

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

...

Removing a reference and deleting a message in DB should be wrapped in a single transaction in JDBCPersistenceManager ---------------------------------------------------------------------------------------------------------------------- Key: JBMESSAGING-1826 URL: https://issues.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.CP15, 1.4.8.SP8 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.

Doug Grove (JIRA)

Tuesday, 22 May Tue, 22 May

12:05 p.m.

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

[ https://issues.jboss.org/browse/JBMESSAGING-1826?page=com.atlassian.jira.... ] Doug Grove updated JBMESSAGING-1826: ------------------------------------ Description: 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. Also, this can affect some database replication mechanisms - see Case 00595385. The customer is running MySQL with replication. was: 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.

...

Removing a reference and deleting a message in DB should be wrapped in a single transaction in JDBCPersistenceManager ---------------------------------------------------------------------------------------------------------------------- Key: JBMESSAGING-1826 URL: https://issues.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.CP15, 1.4.8.SP8 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. Also, this can affect some database replication mechanisms - see Case 00595385. The customer is running MySQL with replication.

Yong Hao Gao (JIRA)

Wednesday, 23 May Wed, 23 May

6:38 a.m.

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

[ https://issues.jboss.org/browse/JBMESSAGING-1826?page=com.atlassian.jira.... ] Yong Hao Gao closed JBMESSAGING-1826. ------------------------------------- Resolution: Done

...

Removing a reference and deleting a message in DB should be wrapped in a single transaction in JDBCPersistenceManager ---------------------------------------------------------------------------------------------------------------------- Key: JBMESSAGING-1826 URL: https://issues.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.CP15, 1.4.8.SP8 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. Also, this can affect some database replication mechanisms - see Case 00595385. The customer is running MySQL with replication.

4613

days inactive

5182

days old

jboss-jira@lists.jboss.org

Manage subscription

18 comments

4 participants

tags (0)

participants (4)

Doug Grove (JIRA)
Tim Fox (JIRA)
Yong Hao Gao (JIRA)
Yong Hao Gao (Updated) (JIRA)

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

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