[JBoss JIRA] Created: (JBMESSAGING-520) Messages received from Receiver.receive() using an XA are never deleted from the database if not withing a transactional boundary.
10:12 a.m.
Messages received from Receiver.receive() using an XA are never deleted from the database
if not withing a transactional boundary.
----------------------------------------------------------------------------------------------------------------------------------
Key: JBMESSAGING-520
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-520
Project: JBoss Messaging
Issue Type: Feature Request
Components: Messaging Core
Affects Versions: 1.0.1.CR4
Environment: Windows XP, JBossServer4.0.4GA, Oracle10G
Reporter: Joel Lindheimer
Assigned To: Ovidiu Feodorov
Create a simple receiver, but do not place it within a Transaction boundary; shut down the
server; look up the tables and you will see all the messages are still in the Messages and
MessageRef tables.
=========================================
Observations using a debbuger reveal the following:
=========================================
Looking over the org.jboss.resource.adapter.jms.JmsManagedConnection the setup method will
always call createXAQueueSession() and create an XAQueconnection as transacted and
Session.SESSION_TRANSACTED. That being the case, non-XA Queues have no message-deletion
problems with the current version (RC4) because the API removes all messages that are
"not transacted and (!ack==1). I am guessing that using XA is problematic because the
persistence layer is expecting manipulation of the transacted XASession--which for some
reason is not working in this version of Messaging. More specifically, I suspect that when
MDBs are tested you are not seeing this problem because the container is doing needed
magic to manage the XASession transacted state, and therefore everything works fine
therein. And consequently, when operating as a non-MDB client, AKA a simple Receiver,
there is something missing in the equation ergo the problems that I have been reporting
regarding the ClickCommerce applications which use Receivers and not MDBs.
Work-around: None; the strategy for my team is to NOT use an XAQueueConnection while
waiting for a fix.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:34 p.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-520) Messages received from Receiver.receive() using an XA are never deleted from the database if not withing a transactional boundary.
[ http://jira.jboss.com/jira/browse/JBMESSAGING-520?page=all ]
Joel Lindheimer updated JBMESSAGING-520:
----------------------------------------
Issue Type: Bug (was: Feature Request)
Messages received from Receiver.receive() using an XA are never
deleted from the database if not withing a transactional boundary.
----------------------------------------------------------------------------------------------------------------------------------
Key: JBMESSAGING-520
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-520
Project: JBoss Messaging
Issue Type: Bug
Components: Messaging Core
Affects Versions: 1.0.1.CR4
Environment: Windows XP, JBossServer4.0.4GA, Oracle10G
Reporter: Joel Lindheimer
Assigned To: Ovidiu Feodorov
Create a simple receiver, but do not place it within a Transaction boundary; shut down
the server; look up the tables and you will see all the messages are still in the Messages
and MessageRef tables.
=========================================
Observations using a debbuger reveal the following:
=========================================
Looking over the org.jboss.resource.adapter.jms.JmsManagedConnection the setup method
will always call createXAQueueSession() and create an XAQueconnection as transacted and
Session.SESSION_TRANSACTED. That being the case, non-XA Queues have no message-deletion
problems with the current version (RC4) because the API removes all messages that are
"not transacted and (!ack==1). I am guessing that using XA is problematic because the
persistence layer is expecting manipulation of the transacted XASession--which for some
reason is not working in this version of Messaging. More specifically, I suspect that when
MDBs are tested you are not seeing this problem because the container is doing needed
magic to manage the XASession transacted state, and therefore everything works fine
therein. And consequently, when operating as a non-MDB client, AKA a simple Receiver,
there is something missing in the equation ergo the problems that I have been reporting
regarding the ClickCommerce applications which use Receivers and not MDBs.
Work-around: None; the strategy for my team is to NOT use an XAQueueConnection while
waiting for a fix.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:38 p.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-520) Messages received from Receiver.receive() using an XA are never deleted from the database if not withing a transactional boundary.
[ http://jira.jboss.com/jira/browse/JBMESSAGING-520?page=all ]
Ovidiu Feodorov updated JBMESSAGING-520:
----------------------------------------
Fix Version/s: 1.0.1.CR5
Messages received from Receiver.receive() using an XA are never
deleted from the database if not withing a transactional boundary.
----------------------------------------------------------------------------------------------------------------------------------
Key: JBMESSAGING-520
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-520
Project: JBoss Messaging
Issue Type: Bug
Components: Messaging Core
Affects Versions: 1.0.1.CR4
Environment: Windows XP, JBossServer4.0.4GA, Oracle10G
Reporter: Joel Lindheimer
Assigned To: Ovidiu Feodorov
Fix For: 1.0.1.CR5
Create a simple receiver, but do not place it within a Transaction boundary; shut down
the server; look up the tables and you will see all the messages are still in the Messages
and MessageRef tables.
=========================================
Observations using a debbuger reveal the following:
=========================================
Looking over the org.jboss.resource.adapter.jms.JmsManagedConnection the setup method
will always call createXAQueueSession() and create an XAQueconnection as transacted and
Session.SESSION_TRANSACTED. That being the case, non-XA Queues have no message-deletion
problems with the current version (RC4) because the API removes all messages that are
"not transacted and (!ack==1). I am guessing that using XA is problematic because the
persistence layer is expecting manipulation of the transacted XASession--which for some
reason is not working in this version of Messaging. More specifically, I suspect that when
MDBs are tested you are not seeing this problem because the container is doing needed
magic to manage the XASession transacted state, and therefore everything works fine
therein. And consequently, when operating as a non-MDB client, AKA a simple Receiver,
there is something missing in the equation ergo the problems that I have been reporting
regarding the ClickCommerce applications which use Receivers and not MDBs.
Work-around: None; the strategy for my team is to NOT use an XAQueueConnection while
waiting for a fix.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:23 p.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-520) Messages received from Receiver.receive() using an XA are never deleted from the database if not withing a transactional boundary.
[ http://jira.jboss.com/jira/browse/JBMESSAGING-520?page=all ]
Ovidiu Feodorov updated JBMESSAGING-520:
----------------------------------------
Priority: Critical (was: Major)
Messages received from Receiver.receive() using an XA are never
deleted from the database if not withing a transactional boundary.
----------------------------------------------------------------------------------------------------------------------------------
Key: JBMESSAGING-520
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-520
Project: JBoss Messaging
Issue Type: Bug
Components: Messaging Core
Affects Versions: 1.0.1.CR4
Environment: Windows XP, JBossServer4.0.4GA, Oracle10G
Reporter: Joel Lindheimer
Assigned To: Ovidiu Feodorov
Priority: Critical
Fix For: 1.0.1.CR5
Create a simple receiver, but do not place it within a Transaction boundary; shut down
the server; look up the tables and you will see all the messages are still in the Messages
and MessageRef tables.
=========================================
Observations using a debbuger reveal the following:
=========================================
Looking over the org.jboss.resource.adapter.jms.JmsManagedConnection the setup method
will always call createXAQueueSession() and create an XAQueconnection as transacted and
Session.SESSION_TRANSACTED. That being the case, non-XA Queues have no message-deletion
problems with the current version (RC4) because the API removes all messages that are
"not transacted and (!ack==1). I am guessing that using XA is problematic because the
persistence layer is expecting manipulation of the transacted XASession--which for some
reason is not working in this version of Messaging. More specifically, I suspect that when
MDBs are tested you are not seeing this problem because the container is doing needed
magic to manage the XASession transacted state, and therefore everything works fine
therein. And consequently, when operating as a non-MDB client, AKA a simple Receiver,
there is something missing in the equation ergo the problems that I have been reporting
regarding the ClickCommerce applications which use Receivers and not MDBs.
Work-around: None; the strategy for my team is to NOT use an XAQueueConnection while
waiting for a fix.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:23 p.m.
New subject: [JBoss JIRA] Commented: (JBMESSAGING-520) Messages received from Receiver.receive() using an XA are never deleted from the database if not withing a transactional boundary.
[ http://jira.jboss.com/jira/browse/JBMESSAGING-520?page=comments#action_12... ]
Ovidiu Feodorov commented on JBMESSAGING-520:
---------------------------------------------
Added JCAWrapperTest.testReceiveNoGlobalTransaction(). It currently fails.
Messages received from Receiver.receive() using an XA are never
deleted from the database if not withing a transactional boundary.
----------------------------------------------------------------------------------------------------------------------------------
Key: JBMESSAGING-520
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-520
Project: JBoss Messaging
Issue Type: Bug
Components: Messaging Core
Affects Versions: 1.0.1.CR4
Environment: Windows XP, JBossServer4.0.4GA, Oracle10G
Reporter: Joel Lindheimer
Assigned To: Ovidiu Feodorov
Fix For: 1.0.1.CR5
Create a simple receiver, but do not place it within a Transaction boundary; shut down
the server; look up the tables and you will see all the messages are still in the Messages
and MessageRef tables.
=========================================
Observations using a debbuger reveal the following:
=========================================
Looking over the org.jboss.resource.adapter.jms.JmsManagedConnection the setup method
will always call createXAQueueSession() and create an XAQueconnection as transacted and
Session.SESSION_TRANSACTED. That being the case, non-XA Queues have no message-deletion
problems with the current version (RC4) because the API removes all messages that are
"not transacted and (!ack==1). I am guessing that using XA is problematic because the
persistence layer is expecting manipulation of the transacted XASession--which for some
reason is not working in this version of Messaging. More specifically, I suspect that when
MDBs are tested you are not seeing this problem because the container is doing needed
magic to manage the XASession transacted state, and therefore everything works fine
therein. And consequently, when operating as a non-MDB client, AKA a simple Receiver,
there is something missing in the equation ergo the problems that I have been reporting
regarding the ClickCommerce applications which use Receivers and not MDBs.
Work-around: None; the strategy for my team is to NOT use an XAQueueConnection while
waiting for a fix.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:17 p.m.
New subject: [JBoss JIRA] Closed: (JBMESSAGING-520) Messages received from Receiver.receive() using an XA are never deleted from the database if not withing a transactional boundary.
[ http://jira.jboss.com/jira/browse/JBMESSAGING-520?page=all ]
Ovidiu Feodorov closed JBMESSAGING-520.
---------------------------------------
Resolution: Done
Modified an XASession to behave as a non-transactional session, unless associated with a
global transaction. See
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968696 for more
details.
Messages received from Receiver.receive() using an XA are never
deleted from the database if not withing a transactional boundary.
----------------------------------------------------------------------------------------------------------------------------------
Key: JBMESSAGING-520
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-520
Project: JBoss Messaging
Issue Type: Bug
Components: Messaging Core
Affects Versions: 1.0.1.CR4
Environment: Windows XP, JBossServer4.0.4GA, Oracle10G
Reporter: Joel Lindheimer
Assigned To: Ovidiu Feodorov
Priority: Critical
Fix For: 1.0.1.CR5
Create a simple receiver, but do not place it within a Transaction boundary; shut down
the server; look up the tables and you will see all the messages are still in the Messages
and MessageRef tables.
=========================================
Observations using a debbuger reveal the following:
=========================================
Looking over the org.jboss.resource.adapter.jms.JmsManagedConnection the setup method
will always call createXAQueueSession() and create an XAQueconnection as transacted and
Session.SESSION_TRANSACTED. That being the case, non-XA Queues have no message-deletion
problems with the current version (RC4) because the API removes all messages that are
"not transacted and (!ack==1). I am guessing that using XA is problematic because the
persistence layer is expecting manipulation of the transacted XASession--which for some
reason is not working in this version of Messaging. More specifically, I suspect that when
MDBs are tested you are not seeing this problem because the container is doing needed
magic to manage the XASession transacted state, and therefore everything works fine
therein. And consequently, when operating as a non-MDB client, AKA a simple Receiver,
there is something missing in the equation ergo the problems that I have been reporting
regarding the ClickCommerce applications which use Receivers and not MDBs.
Work-around: None; the strategy for my team is to NOT use an XAQueueConnection while
waiting for a fix.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:52 a.m.
New subject: [JBoss JIRA] Reopened: (JBMESSAGING-520) Messages received from Receiver.receive() using an XA are never deleted from the database if not withing a transactional boundary.
[ http://jira.jboss.com/jira/browse/JBMESSAGING-520?page=all ]
Ovidiu Feodorov reopened JBMESSAGING-520:
-----------------------------------------
Reopening the issue, as Messaging-layer level changes required to fix
http://jira.jboss.org/jira/browse/JBMESSAGING-721 will modify again the behavior described
here. The changes will be made public in 1.0.1.SP4 and 1.2.0.CR1.
The way an XASession behaves in absence of a JTA transaction is incompletely specified, so
it is inevitable that different implemenation would work differently. Ultimately, it's
up to the JCA layer, not the JMS layer, to enforce a certain behavior. For more
discussions on the subject, please also read
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=98577.
The issue will stay open until after the 1.2.0.GA release, when we will have more time to
experiment with controversial subjects like this
Messages received from Receiver.receive() using an XA are never
deleted from the database if not withing a transactional boundary.
----------------------------------------------------------------------------------------------------------------------------------
Key: JBMESSAGING-520
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-520
Project: JBoss Messaging
Issue Type: Bug
Components: Messaging Core
Affects Versions: 1.0.1.CR4, 1.2.0.Beta2, 1.0.1.SP4
Environment: Windows XP, JBossServer4.0.4GA, Oracle10G
Reporter: Joel Lindheimer
Assigned To: Ovidiu Feodorov
Priority: Critical
Fix For: 1.0.1.CR5, 1.2.1
Create a simple receiver, but do not place it within a Transaction boundary; shut down
the server; look up the tables and you will see all the messages are still in the Messages
and MessageRef tables.
=========================================
Observations using a debbuger reveal the following:
=========================================
Looking over the org.jboss.resource.adapter.jms.JmsManagedConnection the setup method
will always call createXAQueueSession() and create an XAQueconnection as transacted and
Session.SESSION_TRANSACTED. That being the case, non-XA Queues have no message-deletion
problems with the current version (RC4) because the API removes all messages that are
"not transacted and (!ack==1). I am guessing that using XA is problematic because the
persistence layer is expecting manipulation of the transacted XASession--which for some
reason is not working in this version of Messaging. More specifically, I suspect that when
MDBs are tested you are not seeing this problem because the container is doing needed
magic to manage the XASession transacted state, and therefore everything works fine
therein. And consequently, when operating as a non-MDB client, AKA a simple Receiver,
there is something missing in the equation ergo the problems that I have been reporting
regarding the ClickCommerce applications which use Receivers and not MDBs.
Work-around: None; the strategy for my team is to NOT use an XAQueueConnection while
waiting for a fix.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:52 a.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-520) Messages received from Receiver.receive() using an XA are never deleted from the database if not withing a transactional boundary.
[ http://jira.jboss.com/jira/browse/JBMESSAGING-520?page=all ]
Ovidiu Feodorov updated JBMESSAGING-520:
----------------------------------------
Fix Version/s: 1.2.1
Affects Version/s: 1.2.0.Beta2
1.0.1.SP4
Messages received from Receiver.receive() using an XA are never
deleted from the database if not withing a transactional boundary.
----------------------------------------------------------------------------------------------------------------------------------
Key: JBMESSAGING-520
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-520
Project: JBoss Messaging
Issue Type: Bug
Components: Messaging Core
Affects Versions: 1.0.1.CR4, 1.2.0.Beta2, 1.0.1.SP4
Environment: Windows XP, JBossServer4.0.4GA, Oracle10G
Reporter: Joel Lindheimer
Assigned To: Ovidiu Feodorov
Priority: Critical
Fix For: 1.0.1.CR5, 1.2.1
Create a simple receiver, but do not place it within a Transaction boundary; shut down
the server; look up the tables and you will see all the messages are still in the Messages
and MessageRef tables.
=========================================
Observations using a debbuger reveal the following:
=========================================
Looking over the org.jboss.resource.adapter.jms.JmsManagedConnection the setup method
will always call createXAQueueSession() and create an XAQueconnection as transacted and
Session.SESSION_TRANSACTED. That being the case, non-XA Queues have no message-deletion
problems with the current version (RC4) because the API removes all messages that are
"not transacted and (!ack==1). I am guessing that using XA is problematic because the
persistence layer is expecting manipulation of the transacted XASession--which for some
reason is not working in this version of Messaging. More specifically, I suspect that when
MDBs are tested you are not seeing this problem because the container is doing needed
magic to manage the XASession transacted state, and therefore everything works fine
therein. And consequently, when operating as a non-MDB client, AKA a simple Receiver,
there is something missing in the equation ergo the problems that I have been reporting
regarding the ClickCommerce applications which use Receivers and not MDBs.
Work-around: None; the strategy for my team is to NOT use an XAQueueConnection while
waiting for a fix.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:31 p.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-520) Messages received from Receiver.receive() using an XA are never deleted from the database if not withing a transactional boundary.
[ http://jira.jboss.com/jira/browse/JBMESSAGING-520?page=all ]
Ovidiu Feodorov updated JBMESSAGING-520:
----------------------------------------
Fix Version/s: Unscheduled
(was: 1.0.1.CR5)
(was: 1.2.1)
Messages received from Receiver.receive() using an XA are never
deleted from the database if not withing a transactional boundary.
----------------------------------------------------------------------------------------------------------------------------------
Key: JBMESSAGING-520
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-520
Project: JBoss Messaging
Issue Type: Bug
Components: Messaging Core
Affects Versions: 1.0.1.CR4, 1.2.0.Beta2, 1.0.1.SP4
Environment: Windows XP, JBossServer4.0.4GA, Oracle10G
Reporter: Joel Lindheimer
Assigned To: Ovidiu Feodorov
Priority: Critical
Fix For: Unscheduled
Create a simple receiver, but do not place it within a Transaction boundary; shut down
the server; look up the tables and you will see all the messages are still in the Messages
and MessageRef tables.
=========================================
Observations using a debbuger reveal the following:
=========================================
Looking over the org.jboss.resource.adapter.jms.JmsManagedConnection the setup method
will always call createXAQueueSession() and create an XAQueconnection as transacted and
Session.SESSION_TRANSACTED. That being the case, non-XA Queues have no message-deletion
problems with the current version (RC4) because the API removes all messages that are
"not transacted and (!ack==1). I am guessing that using XA is problematic because the
persistence layer is expecting manipulation of the transacted XASession--which for some
reason is not working in this version of Messaging. More specifically, I suspect that when
MDBs are tested you are not seeing this problem because the container is doing needed
magic to manage the XASession transacted state, and therefore everything works fine
therein. And consequently, when operating as a non-MDB client, AKA a simple Receiver,
there is something missing in the equation ergo the problems that I have been reporting
regarding the ClickCommerce applications which use Receivers and not MDBs.
Work-around: None; the strategy for my team is to NOT use an XAQueueConnection while
waiting for a fix.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:25 p.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-520) Messages received from Receiver.receive() using an XA are never deleted from the database if not withing a transactional boundary.
[ http://jira.jboss.com/jira/browse/JBMESSAGING-520?page=all ]
Tim Fox updated JBMESSAGING-520:
--------------------------------
Assignee: (was: Ovidiu Feodorov)
Messages received from Receiver.receive() using an XA are never
deleted from the database if not withing a transactional boundary.
----------------------------------------------------------------------------------------------------------------------------------
Key: JBMESSAGING-520
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-520
Project: JBoss Messaging
Issue Type: Bug
Components: Messaging Core
Affects Versions: 1.0.1.CR4, 1.2.0.Beta2, 1.0.1.SP4
Environment: Windows XP, JBossServer4.0.4GA, Oracle10G
Reporter: Joel Lindheimer
Priority: Critical
Fix For: Unscheduled
Create a simple receiver, but do not place it within a Transaction boundary; shut down
the server; look up the tables and you will see all the messages are still in the Messages
and MessageRef tables.
=========================================
Observations using a debbuger reveal the following:
=========================================
Looking over the org.jboss.resource.adapter.jms.JmsManagedConnection the setup method
will always call createXAQueueSession() and create an XAQueconnection as transacted and
Session.SESSION_TRANSACTED. That being the case, non-XA Queues have no message-deletion
problems with the current version (RC4) because the API removes all messages that are
"not transacted and (!ack==1). I am guessing that using XA is problematic because the
persistence layer is expecting manipulation of the transacted XASession--which for some
reason is not working in this version of Messaging. More specifically, I suspect that when
MDBs are tested you are not seeing this problem because the container is doing needed
magic to manage the XASession transacted state, and therefore everything works fine
therein. And consequently, when operating as a non-MDB client, AKA a simple Receiver,
there is something missing in the equation ergo the problems that I have been reporting
regarding the ClickCommerce applications which use Receivers and not MDBs.
Work-around: None; the strategy for my team is to NOT use an XAQueueConnection while
waiting for a fix.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:49 a.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-520) Messages received from Receiver.receive() using an XA are never deleted from the database if not withing a transactional boundary.
[ http://jira.jboss.com/jira/browse/JBMESSAGING-520?page=all ]
Tim Fox updated JBMESSAGING-520:
--------------------------------
Fix Version/s: 1.2.1.CR1
(was: Unscheduled)
Messages received from Receiver.receive() using an XA are never
deleted from the database if not withing a transactional boundary.
----------------------------------------------------------------------------------------------------------------------------------
Key: JBMESSAGING-520
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-520
Project: JBoss Messaging
Issue Type: Bug
Components: Messaging Core
Affects Versions: 1.0.1.CR4, 1.2.0.Beta2, 1.0.1.SP4
Environment: Windows XP, JBossServer4.0.4GA, Oracle10G
Reporter: Joel Lindheimer
Priority: Critical
Fix For: 1.2.1.CR1
Create a simple receiver, but do not place it within a Transaction boundary; shut down
the server; look up the tables and you will see all the messages are still in the Messages
and MessageRef tables.
=========================================
Observations using a debbuger reveal the following:
=========================================
Looking over the org.jboss.resource.adapter.jms.JmsManagedConnection the setup method
will always call createXAQueueSession() and create an XAQueconnection as transacted and
Session.SESSION_TRANSACTED. That being the case, non-XA Queues have no message-deletion
problems with the current version (RC4) because the API removes all messages that are
"not transacted and (!ack==1). I am guessing that using XA is problematic because the
persistence layer is expecting manipulation of the transacted XASession--which for some
reason is not working in this version of Messaging. More specifically, I suspect that when
MDBs are tested you are not seeing this problem because the container is doing needed
magic to manage the XASession transacted state, and therefore everything works fine
therein. And consequently, when operating as a non-MDB client, AKA a simple Receiver,
there is something missing in the equation ergo the problems that I have been reporting
regarding the ClickCommerce applications which use Receivers and not MDBs.
Work-around: None; the strategy for my team is to NOT use an XAQueueConnection while
waiting for a fix.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:31 p.m.
New subject: [JBoss JIRA] Closed: (JBMESSAGING-520) Messages received from Receiver.receive() using an XA are never deleted from the database if not withing a transactional boundary.
[ http://jira.jboss.com/jira/browse/JBMESSAGING-520?page=all ]
Clebert Suconic closed JBMESSAGING-520.
---------------------------------------
Resolution: Duplicate Issue
this is a duplicate of http://jira.jboss.com/jira/browse/JBMESSAGING-946 and was fixed as
part of that.
Thanks for the bug report though... this will be fixed as part of our next SP releases on
1.0 and 1.2
Messages received from Receiver.receive() using an XA are never
deleted from the database if not withing a transactional boundary.
----------------------------------------------------------------------------------------------------------------------------------
Key: JBMESSAGING-520
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-520
Project: JBoss Messaging
Issue Type: Bug
Components: Messaging Core
Affects Versions: 1.0.1.CR4, 1.2.0.Beta2, 1.0.1.SP4
Environment: Windows XP, JBossServer4.0.4GA, Oracle10G
Reporter: Joel Lindheimer
Priority: Critical
Fix For: 1.2.1.CR1
Create a simple receiver, but do not place it within a Transaction boundary; shut down
the server; look up the tables and you will see all the messages are still in the Messages
and MessageRef tables.
=========================================
Observations using a debbuger reveal the following:
=========================================
Looking over the org.jboss.resource.adapter.jms.JmsManagedConnection the setup method
will always call createXAQueueSession() and create an XAQueconnection as transacted and
Session.SESSION_TRANSACTED. That being the case, non-XA Queues have no message-deletion
problems with the current version (RC4) because the API removes all messages that are
"not transacted and (!ack==1). I am guessing that using XA is problematic because the
persistence layer is expecting manipulation of the transacted XASession--which for some
reason is not working in this version of Messaging. More specifically, I suspect that when
MDBs are tested you are not seeing this problem because the container is doing needed
magic to manage the XASession transacted state, and therefore everything works fine
therein. And consequently, when operating as a non-MDB client, AKA a simple Receiver,
there is something missing in the equation ergo the problems that I have been reporting
regarding the ClickCommerce applications which use Receivers and not MDBs.
Work-around: None; the strategy for my team is to NOT use an XAQueueConnection while
waiting for a fix.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6443
days inactive
6703
days old
11 comments
5 participants
participants (5)
-
Clebert Suconic (JIRA) -
Joel Lindheimer (JIRA) -
Ovidiu Feodorov (JIRA)
-
Ovidiu Feodorov (JIRA)
-
Tim Fox (JIRA)