[JBoss JIRA] (JBTM-2677) XATerminator.rollback does not invoke XAResource.rollback for failed resources when JTS is used
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2677?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson edited comment on JBTM-2677 at 6/10/16 10:58 AM:
---------------------------------------------------------------
{code}
public final int doPhase2Abort ()
{
if (jtsLogger.logger.isTraceEnabled()) {
jtsLogger.logger.trace("ServerTransaction::doPhase2Abort ( "
+ get_uid() + " )");
}
/*
* If the transaction has already terminated, then return the status. If
* there hasn't been a heuristic outcome then we try to massage the result
* to be consistent with what the caller expects: the fact that the
* transaction is marked as committed during prepare without any problems means
* that the intentions lists are zero so it's fine to say that it aborted instead.
*/
org.omg.CosTransactions.Status s = get_status();
if ((s == org.omg.CosTransactions.Status.StatusCommitted)
|| (s == org.omg.CosTransactions.Status.StatusRolledBack))
{
int status = finalStatus();
switch (status)
{
case ActionStatus.COMMITTED:
case ActionStatus.COMMITTING:
case ActionStatus.ABORTED:
case ActionStatus.ABORTING:
return ActionStatus.ABORTED;
default:
return status;
}
}
{code}
This was changed in https://issues.jboss.org/browse/JBTM-507.
was (Author: tomjenkinson):
{code}
public final int doPhase2Abort ()
{
if (jtsLogger.logger.isTraceEnabled()) {
jtsLogger.logger.trace("ServerTransaction::doPhase2Abort ( "
+ get_uid() + " )");
}
/*
* If the transaction has already terminated, then return the status. If
* there hasn't been a heuristic outcome then we try to massage the result
* to be consistent with what the caller expects: the fact that the
* transaction is marked as committed during prepare without any problems means
* that the intentions lists are zero so it's fine to say that it aborted instead.
*/
org.omg.CosTransactions.Status s = get_status();
if ((s == org.omg.CosTransactions.Status.StatusCommitted)
|| (s == org.omg.CosTransactions.Status.StatusRolledBack))
{
int status = finalStatus();
switch (status)
{
case ActionStatus.COMMITTED:
case ActionStatus.COMMITTING:
case ActionStatus.ABORTED:
case ActionStatus.ABORTING:
return ActionStatus.ABORTED;
default:
return status;
}
}
{code}
This was changed in https://issues.jboss.org/browse/JBTM-507.
Prototype: https://github.com/jbosstm/narayana/pull/1019
> XATerminator.rollback does not invoke XAResource.rollback for failed resources when JTS is used
> -----------------------------------------------------------------------------------------------
>
> Key: JBTM-2677
> URL: https://issues.jboss.org/browse/JBTM-2677
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTS
> Affects Versions: 5.2.16.Final
> Reporter: Ondra Chaloupka
> Assignee: Tom Jenkinson
> Fix For: 5.next
>
>
> I do experience an issue of not rollbacking failed XAResource when XATerminator.rollback is called on jca inflow transaction. This works wrong when JTS is used. For the same testcase when JTA is used all in-doubt XAResources are rolled back.
> The scenario is following:
> There is a a test RA which drives an inflow transaction to a MDB. MDB then works with two TestXAResources which are enlisted to the supplied transaction.
> # RAR is deployed
> # RAR opens a java socket where listens for message
> # MDB of TestResourceMessageListener is deployed
> # test client sends prepare command
> # test client sends commit command
> # first TestXAResource commits, second TestXAResource throws XAException.XAER_RMFAIL
> # test client receives error code XAER_RMFAIL
> # test client sends recover command
> # test client receives number of in-doubt xid - which is one
> # test client sends rollback command
> # XATerminator calls rollback on the in-doubt xid
> # expecting TestXAResource.rollback would be called
> After the XATerminator.rollback is invoked there is no call of rollback for the unfinished XAResource. I can see that abort phase is invoked [1] (see attached jboss eap server.log) but the real invocation of the XAResource.rollback does not happen (for the JTA transaction it runs fine).
> [1]
> {code}
> 2016-05-18 11:20:20,385 TRACE [com.arjuna.ats.jts] (default-threads- 1) ServerTransaction::doPhase2Abort (0:ffff7f000001:-728dfa93:573c33bc:24 )
> 2016-05-18 11:20:55,416 TRACE [com.arjuna.ats.jts] (default-threads- 1) ArjunaTransactionImple::get_status for 0:ffff7f000001:-728dfa93:573c33bc:24 returning CosTransactions::StatusCommitted
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (JBTM-2677) XATerminator.rollback does not invoke XAResource.rollback for failed resources when JTS is used
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2677?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson edited comment on JBTM-2677 at 6/10/16 9:28 AM:
--------------------------------------------------------------
{code}
public final int doPhase2Abort ()
{
if (jtsLogger.logger.isTraceEnabled()) {
jtsLogger.logger.trace("ServerTransaction::doPhase2Abort ( "
+ get_uid() + " )");
}
/*
* If the transaction has already terminated, then return the status. If
* there hasn't been a heuristic outcome then we try to massage the result
* to be consistent with what the caller expects: the fact that the
* transaction is marked as committed during prepare without any problems means
* that the intentions lists are zero so it's fine to say that it aborted instead.
*/
org.omg.CosTransactions.Status s = get_status();
if ((s == org.omg.CosTransactions.Status.StatusCommitted)
|| (s == org.omg.CosTransactions.Status.StatusRolledBack))
{
int status = finalStatus();
switch (status)
{
case ActionStatus.COMMITTED:
case ActionStatus.COMMITTING:
case ActionStatus.ABORTED:
case ActionStatus.ABORTING:
return ActionStatus.ABORTED;
default:
return status;
}
}
{code}
This was changed in https://issues.jboss.org/browse/JBTM-507.
Prototype: https://github.com/jbosstm/narayana/pull/1019
was (Author: tomjenkinson):
public final int doPhase2Abort ()
{
if (jtsLogger.logger.isTraceEnabled()) {
jtsLogger.logger.trace("ServerTransaction::doPhase2Abort ( "
+ get_uid() + " )");
}
/*
* If the transaction has already terminated, then return the status. If
* there hasn't been a heuristic outcome then we try to massage the result
* to be consistent with what the caller expects: the fact that the
* transaction is marked as committed during prepare without any problems means
* that the intentions lists are zero so it's fine to say that it aborted instead.
*/
org.omg.CosTransactions.Status s = get_status();
if ((s == org.omg.CosTransactions.Status.StatusCommitted)
|| (s == org.omg.CosTransactions.Status.StatusRolledBack))
{
int status = finalStatus();
switch (status)
{
case ActionStatus.COMMITTED:
case ActionStatus.COMMITTING:
case ActionStatus.ABORTED:
case ActionStatus.ABORTING:
return ActionStatus.ABORTED;
default:
return status;
}
}
This was changed in https://issues.jboss.org/browse/JBTM-507.
Prototype: https://github.com/jbosstm/narayana/pull/1019
> XATerminator.rollback does not invoke XAResource.rollback for failed resources when JTS is used
> -----------------------------------------------------------------------------------------------
>
> Key: JBTM-2677
> URL: https://issues.jboss.org/browse/JBTM-2677
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTS
> Affects Versions: 5.2.16.Final
> Reporter: Ondra Chaloupka
> Assignee: Tom Jenkinson
> Fix For: 5.next
>
>
> I do experience an issue of not rollbacking failed XAResource when XATerminator.rollback is called on jca inflow transaction. This works wrong when JTS is used. For the same testcase when JTA is used all in-doubt XAResources are rolled back.
> The scenario is following:
> There is a a test RA which drives an inflow transaction to a MDB. MDB then works with two TestXAResources which are enlisted to the supplied transaction.
> # RAR is deployed
> # RAR opens a java socket where listens for message
> # MDB of TestResourceMessageListener is deployed
> # test client sends prepare command
> # test client sends commit command
> # first TestXAResource commits, second TestXAResource throws XAException.XAER_RMFAIL
> # test client receives error code XAER_RMFAIL
> # test client sends recover command
> # test client receives number of in-doubt xid - which is one
> # test client sends rollback command
> # XATerminator calls rollback on the in-doubt xid
> # expecting TestXAResource.rollback would be called
> After the XATerminator.rollback is invoked there is no call of rollback for the unfinished XAResource. I can see that abort phase is invoked [1] (see attached jboss eap server.log) but the real invocation of the XAResource.rollback does not happen (for the JTA transaction it runs fine).
> [1]
> {code}
> 2016-05-18 11:20:20,385 TRACE [com.arjuna.ats.jts] (default-threads- 1) ServerTransaction::doPhase2Abort (0:ffff7f000001:-728dfa93:573c33bc:24 )
> 2016-05-18 11:20:55,416 TRACE [com.arjuna.ats.jts] (default-threads- 1) ArjunaTransactionImple::get_status for 0:ffff7f000001:-728dfa93:573c33bc:24 returning CosTransactions::StatusCommitted
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (JBTM-2677) XATerminator.rollback does not invoke XAResource.rollback for failed resources when JTS is used
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2677?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson edited comment on JBTM-2677 at 6/10/16 9:22 AM:
--------------------------------------------------------------
public final int doPhase2Abort ()
{
if (jtsLogger.logger.isTraceEnabled()) {
jtsLogger.logger.trace("ServerTransaction::doPhase2Abort ( "
+ get_uid() + " )");
}
/*
* If the transaction has already terminated, then return the status. If
* there hasn't been a heuristic outcome then we try to massage the result
* to be consistent with what the caller expects: the fact that the
* transaction is marked as committed during prepare without any problems means
* that the intentions lists are zero so it's fine to say that it aborted instead.
*/
org.omg.CosTransactions.Status s = get_status();
if ((s == org.omg.CosTransactions.Status.StatusCommitted)
|| (s == org.omg.CosTransactions.Status.StatusRolledBack))
{
int status = finalStatus();
switch (status)
{
case ActionStatus.COMMITTED:
case ActionStatus.COMMITTING:
case ActionStatus.ABORTED:
case ActionStatus.ABORTING:
return ActionStatus.ABORTED;
default:
return status;
}
}
This was changed in https://issues.jboss.org/browse/JBTM-507.
Prototype: https://github.com/jbosstm/narayana/pull/1019
was (Author: tomjenkinson):
public final int doPhase2Abort ()
{
if (jtsLogger.logger.isTraceEnabled()) {
jtsLogger.logger.trace("ServerTransaction::doPhase2Abort ( "
+ get_uid() + " )");
}
/*
* If the transaction has already terminated, then return the status. If
* there hasn't been a heuristic outcome then we try to massage the result
* to be consistent with what the caller expects: the fact that the
* transaction is marked as committed during prepare without any problems means
* that the intentions lists are zero so it's fine to say that it aborted instead.
*/
org.omg.CosTransactions.Status s = get_status();
if ((s == org.omg.CosTransactions.Status.StatusCommitted)
|| (s == org.omg.CosTransactions.Status.StatusRolledBack))
{
int status = finalStatus();
switch (status)
{
case ActionStatus.COMMITTED:
case ActionStatus.COMMITTING:
case ActionStatus.ABORTED:
case ActionStatus.ABORTING:
return ActionStatus.ABORTED;
default:
return status;
}
}
This was changed in https://issues.jboss.org/browse/JBTM-507. I have had a look at the mentioned particular test if we just return finalStatus it seems to still pass so I think the change may likely be safely reverted.
Prototype: https://github.com/jbosstm/narayana/pull/1019
> XATerminator.rollback does not invoke XAResource.rollback for failed resources when JTS is used
> -----------------------------------------------------------------------------------------------
>
> Key: JBTM-2677
> URL: https://issues.jboss.org/browse/JBTM-2677
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTS
> Affects Versions: 5.2.16.Final
> Reporter: Ondra Chaloupka
> Assignee: Tom Jenkinson
> Fix For: 5.next
>
>
> I do experience an issue of not rollbacking failed XAResource when XATerminator.rollback is called on jca inflow transaction. This works wrong when JTS is used. For the same testcase when JTA is used all in-doubt XAResources are rolled back.
> The scenario is following:
> There is a a test RA which drives an inflow transaction to a MDB. MDB then works with two TestXAResources which are enlisted to the supplied transaction.
> # RAR is deployed
> # RAR opens a java socket where listens for message
> # MDB of TestResourceMessageListener is deployed
> # test client sends prepare command
> # test client sends commit command
> # first TestXAResource commits, second TestXAResource throws XAException.XAER_RMFAIL
> # test client receives error code XAER_RMFAIL
> # test client sends recover command
> # test client receives number of in-doubt xid - which is one
> # test client sends rollback command
> # XATerminator calls rollback on the in-doubt xid
> # expecting TestXAResource.rollback would be called
> After the XATerminator.rollback is invoked there is no call of rollback for the unfinished XAResource. I can see that abort phase is invoked [1] (see attached jboss eap server.log) but the real invocation of the XAResource.rollback does not happen (for the JTA transaction it runs fine).
> [1]
> {code}
> 2016-05-18 11:20:20,385 TRACE [com.arjuna.ats.jts] (default-threads- 1) ServerTransaction::doPhase2Abort (0:ffff7f000001:-728dfa93:573c33bc:24 )
> 2016-05-18 11:20:55,416 TRACE [com.arjuna.ats.jts] (default-threads- 1) ArjunaTransactionImple::get_status for 0:ffff7f000001:-728dfa93:573c33bc:24 returning CosTransactions::StatusCommitted
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (JBTM-2605) Narayana Spring integration
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2605?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-2605:
-------------------------------------
Lets mark this as resolved then
> Narayana Spring integration
> ---------------------------
>
> Key: JBTM-2605
> URL: https://issues.jboss.org/browse/JBTM-2605
> Project: JBoss Transaction Manager
> Issue Type: Task
> Components: Demonstrator, Documentation, JTA
> Reporter: Gytis Trikleris
> Assignee: Gytis Trikleris
> Fix For: 5.next
>
>
> This is a wrapper for all subtasks related with Spring integration.
> As per Tom's request we should improve Narayana integration with Spring and Spring Boot. Also, provide documentation and quickstarts for it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (JBTM-2624) Introduce the administrator tool in the Narayana JTA OSGi integrated with the Karaf
by Amos Feng (JIRA)
[ https://issues.jboss.org/browse/JBTM-2624?page=com.atlassian.jira.plugin.... ]
Issue was automatically transitioned when Amos Feng created pull request #1020 in GitHub
----------------------------------------------------------------------------------------
Status: Pull Request Sent (was: Open)
> Introduce the administrator tool in the Narayana JTA OSGi integrated with the Karaf
> -----------------------------------------------------------------------------------
>
> Key: JBTM-2624
> URL: https://issues.jboss.org/browse/JBTM-2624
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Reporter: Amos Feng
> Assignee: Amos Feng
> Priority: Minor
> Fix For: 5.next
>
>
> {quote}
> We have several management ways in Karaf :
> * mbeans (no need to rewrap them)
> * shell commands
> * a servlet for the felix web console (used by the community)
> * a hawtio plugin (used by fuse)
> The first two are the most important imho.
> {quote}
> the manual interventions that may be needed if the heuristic fails to rollback / commit the transactions.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (JBTM-2605) Narayana Spring integration
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-2605?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris commented on JBTM-2605:
---------------------------------------
I think that it is. Unless there were other requirements for just Spring integration other than a quickstart.
> Narayana Spring integration
> ---------------------------
>
> Key: JBTM-2605
> URL: https://issues.jboss.org/browse/JBTM-2605
> Project: JBoss Transaction Manager
> Issue Type: Task
> Components: Demonstrator, Documentation, JTA
> Reporter: Gytis Trikleris
> Assignee: Gytis Trikleris
> Fix For: 5.next
>
>
> This is a wrapper for all subtasks related with Spring integration.
> As per Tom's request we should improve Narayana integration with Spring and Spring Boot. Also, provide documentation and quickstarts for it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months