Intermittent JTA commit bug----WLS 7.0SP2 on XP

[M Zaidel]

My app is throwing intermittent exceptions (see appended) during the commit() (and
sometimes the rollback()) of a container-managed transaction. The particular
method has a transaction attribute of 'Required' and is executed outside of a
global JTA transaction. The method obtains a database connection (Informix 9.4.0.TC3)
from a TxDataSource using the com.informix.jdbcx.IfxDataSource driver, executes
a SELECT query, then calls close() on the connection. From the SQLException that's
caught and wrapped as an XAException, though,
it appears that when the container attempts to commit() upon exiting the method,
it finds the connection closed. As I said, this exception is intermittent---I
can run the same test driver many times with success before this exception occurs.

Any ideas what may be causing this?

Thanks,

Martin
[exec] <1/04/2004 16:50:53> <Error> <JTA> <110412> <16062:4ccbe42c82f49b02
completed heuristically: (agentPool, HeuristicHazard, (javax.transaction.xa.XAException:
java.sql.SQLException: System or internal error java.net.SocketException: Socket
closed)) >
[exec] <1/04/2004 16:50:53> <Error> <EJB> <010026> <Exception during commit
of transaction 16062:4ccbe42c82f49b02: javax.transaction.HeuristicMixedException:
(agentisPool, HeuristicHazard, (javax.transaction.xa.XAException: java.sql.SQLException:
System or internal error java.net.SocketException: Socket closed))
[exec] at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:258)
[exec] at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransactionImpl.java:208)
[exec] at weblogic.ejb20.internal.BaseEJBObject.postInvoke(BaseEJBObject.java:278)
[exec] at gema.func.user.UserManager_EjbImpl_x658ay_EOImpl.authenticate(UserManager_EjbImpl_x658ay_EOImpl.java:1028)

[M Zaidel]

FYI, I believe I've traced this problem to the JDBC connection pool shrink: By
setting ShrinkPeriodMinutes=2 and ShrinkingEnabled="true", I can make the problem
appear much faster. Conversely, disabling shrinking (ShrinkingEnabled="false")
seems to make it go away.

Has anyone else encountered such behaviour in the pool management?

Thanks,

Martin

[Joe Weinstein]

M Zaidel wrote:

Hi. That's a big clue. The issue seems to be that Oracle's XA implementation
doesn't let transactions survive if the connection that starts them is closed
before the tx goes into the PREPARED state. XA allows connections to operate on
transactions at a fine granularity, per method call, rather than having to
dedicate the connection for the whole length of the tx. As such, an XA connection
may be put back into the pool when it has contributed to 1 or more currently-unfinished
TXs, and can be reused again later by re-joining any of those TXs. However, if you
configure the pool to continually minimize it's size, we may incur the Oracle XA
issue I described. The two options you have are:
1 - Simply configure the pool for the most performance and stability. This is to
define the initial capacity to equal the max capacity. Then all connections will be
made at startup, and no runtime user will ever have to wait (a long time) for the
pool to make a new real DBMS connection.
2 - If you cannot have the initial capacity equal the max, such as needing to be
able to start WLS when the DBMS is down, then at least turn off shrinking, so the
pool grows to max and then stays that way.
3 - Finally, if you must shed unused pool connections, there is a WLS JTA option
that will tell the server to retain a given XA connection for a given TX for the
duration of the TX. This may have some drag on concurrency, but will prevent a
connection from exposure to culling while it is involved in any way with a TX.
Joe
>
> Thanks,
>
> Martin
>

[M Zaidel]

Thanks for the feedback. I note, though, that you mention Oracle, whereas I'm
using Informix. Is that a typo on your part and you mean to speak for Informix's
XA implementation?

Finally, the issue I now face is releasing a JTA-based application to a customer
where this problem *may* appear: do we simply document it and strenuously emphasize
how to configure their JDBC pools, or is there a patch or alternate version of
the server that we can recommend?

thanks,

Martin

[Joe Weinstein]

Ok, then there must be a similar problem with Informix too... All versions of the
server offer pooling and shrinking, so the thing to do is to strongly recommend
no shrinking for the pool configuration, or configuring that XA connections
be devoted to one tx till completion.
Joe