Thanks. I will try to port the new xa wrapper back to 3.2 in the next
couple of days. I'm not worried about the (MyVendorConnection)
ds.getConnection() problem since you can get the vendor connection with
getUnderlyingConnection().
Thanks!!
david jencks
On 2002.11.04 18:09:32 -0500 Igor Fedo
Your proposal will break almost any usage of local tx jdbc. If you really
feel this is the best solution please write a separate ConnectionManager
not used by the LocalTx stuff.
I think your solution is also woefully inefficient as it ties up many xa
connections for just one transaction.
I would
I've looked at this in more detail and am 99.9% sure this proposal is a bad
idea. I think it will break local tx support.
I also think using the 4.0 xa wrapper will solve the problem.
Also, the jdbc spec you quote seems to me to effectively prohibit holding a
jdbc connection from an xa or pooled
1. I see the problem with the old xa wrapper.
2. I will look at this further later.
3. I think your proposal will break the local tx behavior (maybe I didn't
look far enough, I have to run)
4. Won't the new xa wrapper in jboss 4 also solve the problem by always
using the same Connection from the
I don't understand. Can you repeat your explanation of the problem clearly
indicating what is a ManagedConnection and what is a Connection? From your
description it looks like perhaps the problem is that we are reusing the
java.sql.Connection obtained from a XAConnection? This would not be a
pro
Hi,
There is a problem with trackConnectionByTx in the current CVS version
of JBoss 3.2 which occurs when two beans access the same datasource
from the same transaction. I am not 100% sure about original
implementation intends and would like to give others an opportunity to
complain before I che