[jboss-jira] [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.

Ovidiu Feodorov (JIRA) jira-events at jboss.com
Thu Feb 1 01:52:31 EST 2007


     [ 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

       




More information about the jboss-jira mailing list