Bugs item #673249, was opened at 2003-01-23 18: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: David Jencks (d_jencks)
Date: 2003-01-27 05: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
