Weblogic leaves in-doubt transaction on Oracle when it fails

Question

Hi,
I'm looking at resilience with our Weblogic (6.1sp2) and Oracle
(8.1.7) environment, and have been doing a few tests. We're using the
Oracle OCI (thick) driver, in "XA" mode (i.e. using the "Driver"
oracle.jdbc.xa.client.OracleXADataSource). We need to do this because
our application uses JMS/Message driven beans to intiate a lot of the
work, and any database activity that fails needs to be rolled back
together with the message and any other work. We don't "enable
two-phase commit" as shown on the TxDatasource config, so get real XA
behaviour, with JMS and the JDBC connection as the XA resources.
The problem is when/if Weblogic dies. As WLS is the transation
manager, if a transaction is in-flight at the time WLS fails the XA
resources need to take action. If the TM fails after the transaction
starts but before the prepare() calls, it seems as though things
generally work out; Oracle rolls back its transactions, and when WLS
is restarted, the JMS messages are recovered and re-delivered (after
the initial delay period of five minutes). The problem seems to be
when WLS dies between the prepare and the commit. In this case, Oracle
holds the various locks it needs to commit the transaction, and when
WLS is restarted it doesn't seem to inform the XA resources that the
transaction should be rolled back/abandoned. Until a DBA sorts out the
problem, any attempts to use the locked areas (e.g. anything that does
a table scan or uses specific rows) result in errors of the form:
ORA-01591: lock held by in-doubt distributed transaction 18.65.2221
This is sensible as far as Oracle's concerned - it doesn't know if any
other XA resources committed or rolled back their transactions.
However, I'd have expected WLS, as the TM, to have sent the necessary
instructions to Oracle once the transaction has been recovered.
Nothing in WL's logs implies it's trying to do anything with recovered
transactions.
I've managed to make this repeatable. I have a class which I can send
a JMS message to kill the server. This MDB calls
Runtime.getRuntime.halt(1) (to simulate a serious crash) either during
the transaction (in onMessage()) or registers its own "XA killer"
resource which calls halt(1) in the prepare(). In the latter case I
always get an in-doubt transaction.
Anyone else had this behaviour, and more importantly, know how to
resolve it?
James

Answer 1

Lou,
any information about the results of testing of the patch from oracle for 'in-doubt
transaction' problem?
Thanks
Sanjay
"Fei Luo" <[email protected]> wrote:
>
James,
Our support engineer is still testing the patch from Oracle. I
will keep you updated on this.
[email protected] (James Elson) wrote:
"Fei Luo" <[email protected]> wrote in message news:<3cee9c1c$[email protected]>...
Are you using Oracle817? Yes, we are.
There is a known Oracle817 bug that may be related to
your problem. You may try Oracle901.Ah. Such an upgrade would have major implications on our architecture.
Do you have any more information on this bug (a bug number etc)?
Would we have to upgrade the server, or just the clients?
James