Bugs item #673249, was opened at 2003-01-23 11:20
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=673249&group_id=22866
Category: JBossServer
Group: v3.2
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Matt Cleveland (groovesoftware)
Assigned to: David Jencks (d_jencks)
Summary: 3.2RC1 Oracle XA Problem
Initial Comment:
I'm running into a problem with Oracle XA in 3.2RC1.
I'm running Oracle 9.2.0.1. I know there have been a
bunch of problems with the Oracle XA driver and I know
some of them are supposed to be fixed in 3.2RC1 but I
think this is yet another Oracle problem.
I have a really simple test. I have a client that starts up
N threads. Each thread calls an EJB. The EJB gets an
Oracle connection (from an XA pool) and inserts a
record into the database and then closes the
connection and returns. This all works fine under lower
load, but the log file shows the stack trace below
occasionally under heavy load. In some cases I then
start getting "ORA-01591: lock held by in-doubt
distributed transaction" on Oracle calls after the error.
The client is not receiving this error. In fact it is only
reported as a warning. Still it's pretty scary to see
these flying by in the log file. It leaves you wondering if
the transaction committed or rolled back. From the
stack trace I believe that the transaction rolled back and
this is still an Oracle concurrency bug, but
if that's not the case I wish the log message told me
that.
I've tried with and without TrackConnectionByTx. My
oracle-xa-ds.xml is pasted below the stack trace.
2003-01-21 21:42:09,141 WARN
[org.jboss.tm.TransactionImpl]
XAException: tx=Tra
nsactionImpl:XidImpl [FormatId=257,
GlobalId=malt//1809, BranchQual=]
errorCode=XAER_RMERR
oracle.jdbc.xa.OracleXAException
at oracle.jdbc.xa.OracleXAResource.checkError
(OracleXAResource.java:1157)
at oracle.jdbc.xa.client.OracleXAResource.commit
(OracleXAResource.java:590)
at
org.jboss.resource.adapter.jdbc.xa.XAManagedConnecti
on.commit(XAManagedConnection.java:140)
at org.jboss.tm.TransactionImpl.commitResources
(TransactionImpl.java:1420)
at org.jboss.tm.TransactionImpl.commit
(TransactionImpl.java:349)
at
org.jboss.ejb.plugins.TxInterceptorCMT.endTransaction
(TxInterceptorCMT.java:361)
at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti
ons(TxInterceptorCMT.java:247)
at org.jboss.ejb.plugins.TxInterceptorCMT.invoke
(TxInterceptorCMT.java:101)
at org.jboss.ejb.plugins.SecurityInterceptor.invoke
(SecurityInterceptor.java:130)
at org.jboss.ejb.plugins.LogInterceptor.invoke
(LogInterceptor.java:204)
at
org.jboss.ejb.plugins.CleanShutdownInterceptor.invoke
(CleanShutdownInterceptor.java:265)
at
org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invo
ke(ProxyFactoryFinderInterceptor.java:154)
at org.jboss.ejb.StatelessSessionContainer.invoke
(StatelessSessionContai
ner.java:303)
at org.jboss.ejb.Container.invoke
(Container.java:680)
at org.jboss.mx.server.MBeanServerImpl.invoke
(MBeanServerImpl.java:549)
at
org.jboss.invocation.jrmp.server.JRMPInvokerHA.invoke
(JRMPInvokerHA.java:163)
at java.lang.reflect.Method.invoke(Native Method)
at sun.rmi.server.UnicastServerRef.dispatch
(UnicastServerRef.java:236)
at sun.rmi.transport.Transport$1.run
(Transport.java:147)
at java.security.AccessController.doPrivileged
(Native Method)
at sun.rmi.transport.Transport.serviceCall
(Transport.java:143)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages
(TCPTransport.java:460)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.r
un(TCPTransport
.java:701)
at java.lang.Thread.run(Thread.java:479)
oracle-xa-ds
------------------
<?xml version="1.0" encoding="UTF-8"?>
<datasources>
<xa-datasource>
<jndi-name>XaOracleDS</jndi-name>
<track-connection-by-tx>true</track-connection-by-
tx>
<managedconnectionfactory-
class>org.jboss.resource.adapter.jdbc.xa.oracle.XAOrac
leManagedConnectionFactory</managedconnectionfacto
ry-class>
<!--xa-datasource-
class>oracle.jdbc.xa.client.OracleXADataSource</xa-
datasource-class-->
<xa-datasource-property
name="URL">jdbc:oracle:thin@server:port:sid</xa-
datasource-property>
<xa-datasource-property name="User">scott</xa-
datasource-property>
<xa-datasource-property
name="Password">tiger</xa-datasource-property>
<min-pool-size>0</min-pool-size>
<max-pool-size>50</max-pool-size>
<blocking-timeout-millis>20000</blocking-timeout-
millis>
<idle-timeout-minutes>15</idle-timeout-minutes>
</xa-datasource>
</datasources>
Thanks,
Matt Cleveland
----------------------------------------------------------------------
>Comment By: Matt Cleveland (groovesoftware)
Date: 2003-01-27 09:35
Message:
Logged In: YES
user_id=85088
Oops, I spoke too soon. The error is NOT being propagated
to the client using the latest CVS for 3.2. Looks like we
need to look further. In my test I received multiple RMERR
exceptions in the server log file, but none were reported to
the test client.
----------------------------------------------------------------------
Comment By: Matt Cleveland (groovesoftware)
Date: 2003-01-27 09:25
Message:
Logged In: YES
user_id=85088
The problem with the error being propagated to the client is
fixed.
I'm not convinced of your answer regarding the RMERR.
First of all, the in-doubt tx error comes after the RMERR,
which makes sense. If JBoss failed to commit or rollback
any transaction for any reason then it would become in-doubt
because Oracle would not know whether it should be
committed or rolled back, right? Second, this RMERR
exception looks very much like the type of exceptions you
will get using JBoss with Oracle if you turn off
TrackConnectionByTX or do not use the
XAOracleManagedConnectionFactory. Now, I'm not saying
it's not an Oracle oddity or a behavior that differs from other
XA drivers, but those are the kinds of things that
TrackConnectionByTX and
XAOracleManagedConnectionFactory are designed to fix. I'm
hoping someone can do the same with this one or at least
rule out the possibility of doing the same.
Just to keep this bug report up to date with some activity in
the dev list, here are the details of how to reproduce the bug.
> Ok, it took a while, but I can confirm that your test
produces the error on
> JBoss 3.2 from CVS with clustering turned off. Two things
you might be
> missing are 1) increasing the thread count in the client to
100 makes it
> more likely to happen more quickly and 2) the test client
does not receive
> the error. The error ONLY shows up in the server log file
(and stdout).
>
> We are using Oracle 9.2.0.1.0. The JDBC driver version is
9.2.0.0.0 as
> reported in the manifest.
>
> Just to make sure I'm not missing something here are all
the boring details
> of what I did.
>
> 1. Got the latest from CVS
> 2. ./build.sh clobber
> 3. built JBoss with integrated Tomcat 4.1.18
> 4. Tweaked TestBean as follows to make it work in my
build environment.
> None of these changes should matter to the test.
> - changed bean name from test/Test to Test
> - changed the view-type to remote because our build
doesn't do
> <localinterface> for xdoclet
> - changed the data source name. Yours was
XAOracleDS and mine is
> XaOracleDS
> - changed the name of your remote interface to
TestRemoteIF to match
> our naming conventions
> 5. made corresponding changes to TestMtClient and
increased the number of
> threads to 100
> 6. built into an EAR
> 7. added my oracle-xa-ds.xml to the default configuration
> 8. turned on Pad in the XidFactory for the transaction
manager in the
> default configuration
> 9. deployed my EAR to the default configuration
> 10. started the default configuration
> 11. ran TestMtClient long enough to get the error. The
error shows up in
> the server log file and stdout.
----------------------------------------------------------------------
Comment By: David Jencks (d_jencks)
Date: 2003-01-26 22:53
Message:
Logged In: YES
user_id=60525
I've fixed the problem with no error showing up to the client in Branch_3_2 cvs.
Please check that the error is being propagated as you expect to the client.
I think the original RMERR may well be an Oracle problem since the stack trace
indicates that onephase commit is being called. In this case any in-doubt transaction
can be in doubt only because Oracle has lost track of its own internal state. (At
least, since jboss is not calling prepare, I can't see how jboss has anything to do
with an in-doubt tx).
You can check the error propagation with running this test:
cd testsuite
./build.sh one-test -Dtest=org.jboss.test.jca.test.XAExceptionUnitTestCase
Please report back your results, if satisfactory I will port to 3.0 and 4 if necessary.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=673249&group_id=22866
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
