David Jencks wrote:
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.
This is what I meant by "better implementation".
Not really, only as many connections are tied with one tx as necessary. So, one connection will be tied if all beans close connection before calling another ejb.I think your solution is also woefully inefficient as it ties up many xa connections for just one transaction.
New wrapper works fine as far as I can tell. Actually, I've found this bug when I tried to migrate my application from 4.0 to 3.2.I would really like to know if the jboss 4 xa wrapper solves the problems, as I think it would, by using the same jdbc connection handle for all jca connection handles. Have you tried it?
Not sure wrapper are you talking about, old one or new one? As I said, new wrapper works fine as it is right now, old wrapper needs some fixes but not hopeless.I am still waiting for some clear feedback on this wrapper on the lines of "It works with Oracle" since I still have some hope of including it in jboss 3.2.
Btw, although I personally do not care ;-), the new wrapper breaks those clients who do "(MyVendorConnection) ds.getConnection()".
thanks david jencks On 2002.11.04 15:02:05 -0500 Igor Fedorenko wrote:David Jencks wrote:I've looked at this in more detail and am 99.9% sure this proposal is abadI agree that suggested implementation breaks local tx and in this sense is "bad". However, I believe that I can write better implementation that deals with XA connections only. If the plan is to backport 4.0 xa wrapper to 3.2 I would be happy to help with it. If the plan is to ship 3.2 with the old xa wrapper, then we should fix this problem in order to support xa-oracle.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 prohibitholding ajdbc connection from an xa or pooled driver while you call another ejb:theconnection will have been closed when the call returns. Therefore, ifyouwant portable code, you MUST close connections before calling anotherejb,1. I guess the spec says that (theoretically) container can reallocate xa connection from a lower priority task to a higher priority task.and if you do this, the problem you are trying to solve disappears.
2. Specification does not require/imply that the same xa connection should or should not be used for nested ejb call. At the same time is specifically says that only one logical handle can be active at any instant. This means that we can implement any connection management schema as long as it does not violate what is explicitly prohibited. I believe that suggested connection management schema (xa connection is associated with a transation but not allocated for more then one ejb call at a time) is perfectly valid.
aIf I missed something please enlighten me. thanks david jencks On 2002.11.01 11:29:09 -0500 Igor Fedorenko wrote:Ok, here is the same example with some more details/comments. There wasa mistake in my original explanation and I apoligize for confusion. BeanA allocates a connection - TxConnectionManager.getManagedConnection allocates new managed connection mc1 of type org.jboss.resource.adapter.jdbc.xa.XAManagedConnection which is a wrapper for (oracle) xa connection xaconn1. - TxConnectionManager.registerConnectionEventListener(mc1) creates new TxConnectionEventListener and calls mc1.addConnectionEventListener - mc1 gets enlisted into the transaction, TxConnectionEventListener.enlist is called and mc1 is added into txToManagedConnectionMap - mc1.getConnection() is called to get sql connection, it gets conn1 through xaconn1.getConnection() BeanA calls BeanB - nothing special here BeanB allocates a connection and gets instance conn2 from the same xaconn1 - TxConnectionManager.getManagedConnection gets mc1 from txToManagedConnectionMap - mc1.getConnection() is called to get sql connection, it gets conn2 through xaconn1.getConnection() and implicitly invalidates conn1 held by BeanA (see quote below) BeanB closes the connection and returns - nothing special BeanA tries to use the connection - SQLException("Logical handle no longer valid"). A quote from JDBC 2.0 stdext, section 6.2.3 "Retrieving a Connection": <quote> An individual PooledConnection object will usually be asked to produce
automaticallyseries of Connection objects during its lifetime. Only one of these Connection objects may be open at a particular point in time. The connection pooling implementation must call PooledConnection.getConnection() each time a new reference to a pooledConnection is handed out to the JDBC application layer. Each call
to PooledConnection.getConnection() must return a newly constructed Connection object that exhibits the default Connection behavior. Only the most recent Connection object produced from a particular PooledConnection is open. An existing Connection object is
someoneclosed, if the getConnection() method of its associated Pooled- Connection is called again, before it has been explicitly closed by theapplication. This gives the application server a way to ‘take away’ a Connection from the application if it wishes, and give it out to
else. This capability will not likely be used frequently in practice. </quote> Attached is a proposed fix. Hope this makes the problem clearer. David Jencks wrote:I don't understand. Can you repeat your explanation of the problemclearlyindicating what is a ManagedConnection and what is a Connection? Fromyourdescription it looks like perhaps the problem is that we are reusingthejava.sql.Connection obtained from a XAConnection? This would not be a problem with the trackConnectionByTx logic but with the xa wrapper. thanks david jencks On 2002.11.01 08:12:05 -0500 Igor Fedorenko wrote:Hi, There is a problem with trackConnectionByTx in the current CVSversiontoof JBoss 3.2 which occurs when two beans access the same datasourcefrom the same transaction. I am not 100% sure about originalimplementation intends and would like to give others an opportunity
complain before I check in updated trackConnectionByTx logic. Consider the following example - BeanA allocates a connection and gets an instance conn1 - BeanA calls BeanB - BeanB allocates a connection and gets the same instance conn1 - BeanB closes the connection and returns - BeanA tries to use the connection and gets SQLException("Logical handle is closed"). Updated trackConnectionByTx logic will return the same connection only if the connection has not been allocated yet (condition "BaseConnectionManager2.ConnectionListener.isManagedConnectionFree()"); otherwise allocate and return new connection. Any objections?-- Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.com Index: TxConnectionManager.java =================================================================== RCS file: /cvsroot/jboss/jbosscx/src/main/org/jboss/resource/connectionmanager/TxConnectionManager.java,v retrieving revision 1.2.2.1 diff -u -r1.2.2.1 TxConnectionManager.java --- TxConnectionManager.java 12 Sep 2002 01:23:46 -0000 1.2.2.1 +++ TxConnectionManager.java 1 Nov 2002 16:06:11 -0000 @@ -13,13 +13,13 @@ import java.util.HashMap; import java.util.HashSet; import java.util.Iterator; +import java.util.List; import java.util.Map; import java.util.Set; -import javax.management.ObjectName; + import javax.naming.InitialContext; import javax.resource.ResourceException; import javax.resource.spi.ConnectionEvent; -import javax.resource.spi.ConnectionEventListener; import javax.resource.spi.ConnectionRequestInfo; import javax.resource.spi.ManagedConnection; import javax.resource.spi.ManagedConnectionFactory; @@ -34,8 +34,6 @@ import javax.transaction.xa.XAResource; import javax.transaction.xa.Xid; -import org.jboss.system.Registry; - import org.jboss.logging.Logger; /** @@ -129,6 +127,7 @@ private boolean localTransactions; + // maps tx => List of connections private final Map txToManagedConnectionMap = new HashMap(); /** @@ -261,8 +260,25 @@ ManagedConnection mc = null; synchronized (txToManagedConnectionMap) { - mc = (ManagedConnection)txToManagedConnectionMap.get(tx); + List conns = (List) txToManagedConnectionMap.get(tx); + if( conns != null ) + { + Iterator i = conns.iterator(); + while( i.hasNext() ) + { + ManagedConnection conn = (ManagedConnection) i.next(); + ConnectionListener listener = getConnectionEventListener(conn); + if( listener != null && listener instanceof TxConnectionEventListener + && ((TxConnectionEventListener) listener)._isManagedConnectionFree() ) + { + mc = conn; + break; + } + } + } +// mc = (ManagedConnection)txToManagedConnectionMap.get(tx); } + // make sure that connection is not allocated by theclientif (mc != null) {
if (log.isTraceEnabled()) @@ -443,7 +459,13 @@
//Here we actually track the cx by tx.
synchronized(txToManagedConnectionMap)
{
- txToManagedConnectionMap.put(currentTx,
this.getManagedConnection());
+ List conns = (List)
txToManagedConnectionMap.get(currentTx);
+ if( conns == null )
+ {
+ conns = new ArrayList();
+ txToManagedConnectionMap.put(currentTx, conns);
+ }
+ conns.add(this.getManagedConnection());
}
} // end of if ()
@@ -576,7 +598,15 @@
{
synchronized(txToManagedConnectionMap)
{
- txToManagedConnectionMap.remove(currentTx);
+ List conns = (List)
txToManagedConnectionMap.get(currentTx);+ if( conns != null ) + { + conns.remove(ce.getConnectionHandle()); + if( conns.isEmpty() ) + { + txToManagedConnectionMap.remove(currentTx); + } + } } } currentTx = null; @@ -595,6 +625,10 @@ { return false; } // end of if () + return super.isManagedConnectionFree(); + } + boolean _isManagedConnectionFree() + { return super.isManagedConnectionFree(); }------------------------------------------------------- This SF.net email is sponsored by: ApacheCon, November 18-21 in Las Vegas (supported by COMDEX), the only Apache event to be fully supported by the ASF. http://www.apachecon.com _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development-- Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.com ------------------------------------------------------- This SF.net email is sponsored by: ApacheCon, November 18-21 in Las Vegas (supported by COMDEX), the only Apache event to be fully supported by the ASF. http://www.apachecon.com _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development------------------------------------------------------- This SF.net email is sponsored by: ApacheCon, November 18-21 in Las Vegas (supported by COMDEX), the only Apache event to be fully supported by the ASF. http://www.apachecon.com _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
-- Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.com ------------------------------------------------------- This SF.net email is sponsored by: ApacheCon, November 18-21 in Las Vegas (supported by COMDEX), the only Apache event to be fully supported by the ASF. http://www.apachecon.com _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
