[JBoss JIRA] Created: (JBTM-187) Problem recovering inbound transaction
by Peter Johnson (JIRA)
Problem recovering inbound transaction
--------------------------------------
Key: JBTM-187
URL: http://jira.jboss.com/jira/browse/JBTM-187
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 4.2.2
Reporter: Peter Johnson
Assigned To: Mark Little
Fix For: 4.2.3, 4.4
I have a custom JCA 1.5 compliant resource adapter (called DTPRA) that I am attempting to test with JBoss Application Server 4.0.5 and JBoss Transactions 4.2.2. DTPRA has already been successfully tested with JBoss 4.0.2 (without recovery) and with BEA WebLogic Server 9.0 and IBM WebSphere Application Server 6.0.1 (both with recovery).
For this scenario, I am using the JBoss Application Server "all" config with the distributed JTA configured.
I ran a test with an inbound transaction to DTPRA using JCA 1.5 transaction inflow. This worked fine with no errors or unexpected warnings.
I ran the same test again with a sleep in DTPRA code so I could test recovery.
Here is a high-level summary of what is happened:
1) DTPRA generated an XID and called XATerminator.prepare with this XID. XATerminator.prepare returned XA_OK, as expected.
2) Everyone involved in the transaction is successfully logged.
3) Before calling XATerminator.commit, I killed the Java process running JBoss.
4) I restarted JBoss.
5) DTPRA called XATerminator.recover and it returned one XID. However, the XID did not match the XID that DTPRA supplied earlier on the XATerminator.prepare call.
6) Later, DTPRA called XATerminator.commit with the the same XID supplied in step 1. This failed with an XAException with an errorCode of XAER_INVAL.
In particular, DTPRA called XATerminator.prepare and XATerminator.commit with the following XID:
0x44545031,
0xa08006092b81403f8176768f520000820400757e21,
0x06092b81403f815561ae73
where the first value is the format ID, the second value is the global transaction ID, and the third value is the branch qualifier. All three values are hexadecimal values, not printable ASCII characters.
The XID returned from XATerminator.recover is the following:
131075,
0x312d2d33666330326139663a3534623a34353736653366373a3935, 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
That is, the global transaction ID is the ASCII string:
1--3fc02a9f_54b_4576e3f7_95
So, I have the following issues:
A) I expected the XID returned from XATerminator.recover to match the XID I supplied earlier to XATerminator.prepare.
B) I expected the call to XATerminator.commit during recovery to succeed.
--
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
19 years, 3 months
[JBoss JIRA] Created: (EJBTHREE-854) Nested SFSB that declares @Remote does not have a dependent lifecycle
by Brian Stansberry (JIRA)
Nested SFSB that declares @Remote does not have a dependent lifecycle
---------------------------------------------------------------------
Key: EJBTHREE-854
URL: http://jira.jboss.com/jira/browse/EJBTHREE-854
Project: EJB 3.0
Issue Type: Bug
Reporter: Brian Stansberry
Assigned To: Carlo de Wolf
Fix For: EJB 3.0 RC10 - FD
Per forum thread:
Bill Burke wrote:
Nested SFSBs have to share the same lifecycle as their parents. They also have to share the same Extended Persistence Contexts the reference!
Brian Stansberry wrote:
This is broken if the nested SFSB declares @Remote. This test fails:
Code:
ParentStatefulRemote stateful = (ParentStatefulRemote) ctx.lookup("testParentStateful/remote");
assertEquals("Counter: ", 1, stateful.increment());
NestedStateful nested = stateful.getNested();
stateful.remove();
// Confirm nested no longer works following parent remove
try
{
nested.increment();
fail("Nested bean still exists following destruction of parent");
}
catch (Exception good)
{
// this is what we want -- nested has no independent lifecycle
}
I've been digging around trying to understand what's going on. For some reason, if the nested bean declares @Remote, when a StatefulCache calls Pool.get(), it gets back a standard StatefulBeanContext rather ProxiedStatefulBeanContext. This has to be a function of how calls are nested (i.e. the nested bean gets created *before* the parent, thus the parent hasn't been pushed onto the ThreadLocalStack when the nested bean is created.)
Test that fails is org.jboss.ejb3.test.stateful.unit.NestedBeanUnitTestCase.testDependentLifecycle().
--
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
19 years, 3 months