You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "Matthew Vaughton (JIRA)" <ji...@apache.org> on 2007/09/18 13:05:43 UTC
[jira] Created: (GERONIMO-3477) Transaction recovery broken for
resource adapter
Transaction recovery broken for resource adapter
------------------------------------------------
Key: GERONIMO-3477
URL: https://issues.apache.org/jira/browse/GERONIMO-3477
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: transaction manager
Affects Versions: 2.0.1
Environment: GA version of Geronimo 2.0.1 running under Windows XP on Intel machine
Reporter: Matthew Vaughton
An external JMS Resource adapter is installed into Geronimo.
XA connections configured on the JMS resource adapter are used by a container managed session EJB to connect and put a message onto two different remote resource manager queues. Both resource managers XA resources receive a preprere call and respond rc=0, ie ok.
The first resource manager is called to commit and it does so ok.
The second resource manager is called to commit at which point we kill the Geronimo server process before the commit is processed.
After restarting the Geronimo server process recover is called on all XA connections, the second resource manager responds to the recover call with the indoubt transaction Xid but instead of the required commit call we receive a rollback call - since the first resource manager has committed the second resource manager must also be called to commit.
This problem was introduced into the Geronimo code base between M6-rc1 and 2.0.1 as the transaction recovery scenario described worked fine in M6-rc1
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3477) Transaction recovery broken for
resource adapter
Posted by "Kevan Miller (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-3477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kevan Miller reassigned GERONIMO-3477:
--------------------------------------
Assignee: Kevan Miller
> Transaction recovery broken for resource adapter
> ------------------------------------------------
>
> Key: GERONIMO-3477
> URL: https://issues.apache.org/jira/browse/GERONIMO-3477
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: transaction manager
> Affects Versions: 2.0.1
> Environment: GA version of Geronimo 2.0.1 running under Windows XP on Intel machine
> Reporter: Matthew Vaughton
> Assignee: Kevan Miller
>
> An external JMS Resource adapter is installed into Geronimo.
> XA connections configured on the JMS resource adapter are used by a container managed session EJB to connect and put a message onto two different remote resource manager queues. Both resource managers XA resources receive a preprere call and respond rc=0, ie ok.
> The first resource manager is called to commit and it does so ok.
> The second resource manager is called to commit at which point we kill the Geronimo server process before the commit is processed.
> After restarting the Geronimo server process recover is called on all XA connections, the second resource manager responds to the recover call with the indoubt transaction Xid but instead of the required commit call we receive a rollback call - since the first resource manager has committed the second resource manager must also be called to commit.
> This problem was introduced into the Geronimo code base between M6-rc1 and 2.0.1 as the transaction recovery scenario described worked fine in M6-rc1
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3477) Transaction recovery broken for
resource adapter
Posted by "Kevan Miller (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-3477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kevan Miller resolved GERONIMO-3477.
------------------------------------
Resolution: Fixed
Fix Version/s: 2.1
2.0.2
Regression: [Regression]
The transaction log wasn't being read properly. This function was regressed by some code restructuring which occurred between M2 and 2.0.
Thanks for catching this. If you could verify, that the problem is fixed and close this issue, that would be great.
You can download a 2.0.2-SNAPSHOT server binary from:
http://people.apache.org/repo/m2-snapshot-repository/org/apache/geronimo/assemblies/geronimo-tomcat6-jee5/2.0.2-SNAPSHOT/geronimo-tomcat6-jee5-2.0.2-20070922.184612-1-bin.zip
or
http://people.apache.org/repo/m2-snapshot-repository/org/apache/geronimo/assemblies/geronimo-jetty6-jee5/2.0.2-SNAPSHOT/geronimo-jetty6-jee5-2.0.2-20070922.184612-1-bin.zip
> Transaction recovery broken for resource adapter
> ------------------------------------------------
>
> Key: GERONIMO-3477
> URL: https://issues.apache.org/jira/browse/GERONIMO-3477
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: transaction manager
> Affects Versions: 2.0.1
> Environment: GA version of Geronimo 2.0.1 running under Windows XP on Intel machine
> Reporter: Matthew Vaughton
> Assignee: Kevan Miller
> Fix For: 2.0.2, 2.1
>
>
> An external JMS Resource adapter is installed into Geronimo.
> XA connections configured on the JMS resource adapter are used by a container managed session EJB to connect and put a message onto two different remote resource manager queues. Both resource managers XA resources receive a preprere call and respond rc=0, ie ok.
> The first resource manager is called to commit and it does so ok.
> The second resource manager is called to commit at which point we kill the Geronimo server process before the commit is processed.
> After restarting the Geronimo server process recover is called on all XA connections, the second resource manager responds to the recover call with the indoubt transaction Xid but instead of the required commit call we receive a rollback call - since the first resource manager has committed the second resource manager must also be called to commit.
> This problem was introduced into the Geronimo code base between M6-rc1 and 2.0.1 as the transaction recovery scenario described worked fine in M6-rc1
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3477) Transaction recovery broken for
resource adapter
Posted by "Matthew Vaughton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-3477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12529481 ]
Matthew Vaughton commented on GERONIMO-3477:
--------------------------------------------
Kevan Miller has access to a test case.
> Transaction recovery broken for resource adapter
> ------------------------------------------------
>
> Key: GERONIMO-3477
> URL: https://issues.apache.org/jira/browse/GERONIMO-3477
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: transaction manager
> Affects Versions: 2.0.1
> Environment: GA version of Geronimo 2.0.1 running under Windows XP on Intel machine
> Reporter: Matthew Vaughton
>
> An external JMS Resource adapter is installed into Geronimo.
> XA connections configured on the JMS resource adapter are used by a container managed session EJB to connect and put a message onto two different remote resource manager queues. Both resource managers XA resources receive a preprere call and respond rc=0, ie ok.
> The first resource manager is called to commit and it does so ok.
> The second resource manager is called to commit at which point we kill the Geronimo server process before the commit is processed.
> After restarting the Geronimo server process recover is called on all XA connections, the second resource manager responds to the recover call with the indoubt transaction Xid but instead of the required commit call we receive a rollback call - since the first resource manager has committed the second resource manager must also be called to commit.
> This problem was introduced into the Geronimo code base between M6-rc1 and 2.0.1 as the transaction recovery scenario described worked fine in M6-rc1
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3477) Transaction recovery broken for
resource adapter
Posted by "Matthew Vaughton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-3477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matthew Vaughton closed GERONIMO-3477.
--------------------------------------
Separate JAR file sent to me works on top of 2.0.1 ok. The snapshot driver JNDI lookups from a J2SE client aren't working so I couldn't test the snapshot driver
> Transaction recovery broken for resource adapter
> ------------------------------------------------
>
> Key: GERONIMO-3477
> URL: https://issues.apache.org/jira/browse/GERONIMO-3477
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: transaction manager
> Affects Versions: 2.0.1
> Environment: GA version of Geronimo 2.0.1 running under Windows XP on Intel machine
> Reporter: Matthew Vaughton
> Assignee: Kevan Miller
> Fix For: 2.0.2, 2.1
>
>
> An external JMS Resource adapter is installed into Geronimo.
> XA connections configured on the JMS resource adapter are used by a container managed session EJB to connect and put a message onto two different remote resource manager queues. Both resource managers XA resources receive a preprere call and respond rc=0, ie ok.
> The first resource manager is called to commit and it does so ok.
> The second resource manager is called to commit at which point we kill the Geronimo server process before the commit is processed.
> After restarting the Geronimo server process recover is called on all XA connections, the second resource manager responds to the recover call with the indoubt transaction Xid but instead of the required commit call we receive a rollback call - since the first resource manager has committed the second resource manager must also be called to commit.
> This problem was introduced into the Geronimo code base between M6-rc1 and 2.0.1 as the transaction recovery scenario described worked fine in M6-rc1
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.