On 2002.09.22 09:34:02 -0400 Igor Fedorenko wrote: > Hi, > > I've been looking at our jdbc connection code yesterday and discovered > that we are caching connections returned by > javax.sql.PooledConnection#getConnection(). In fact, our > XAManagedConnection calls getConnection only to initialize super in > constructor. > > "JDBC 2.0 Standard Extension API" specification seems to explicitly > forbid such behaviour in section 6.2.3 "The connection pooling > implementation must call PooledConnection.getConnection() each time a > new reference to a PooledConnection is handed out to the JDBC > application layer". I could not find similar statement in JDBC 3.0 spec, > but both version stress that Connection returned by > PooledConnection.getConnection() is "a logical handle to an underlying > physical connection" and overhead of getting such handles is little. > > So my question: why do we do something that is against the spec and does > not buy us much? > > As a side note, why do we ignore PooledConnection functionality provided > by JDBC driver vendor and work with all connections as if they were > instances of plain java.sql.Connection? Would not it be better to build > our connection pooling on top of PooledConnection (all xa connections > will be supported directly) and provide PooledConnection wrapper for > plain connections?
The PooledConnection concept morphed into the ManagedConnection jca concept, which supports more features better. I think we would be moving backward to wrap Connections from DriverManager in PooledConnection, then in ManagedConnection. We'd just have another useless wrapper layer. With an XAConnection, we could get a new Connection each time we generate a new wrapper, but I don't see that this would provide any additional functionality. If you want to write it, go ahead, but please don't increase the code complexity a lot. Are you experiencing a problem with the current code? The main benefit of the current code is that we have it, AFAIK it works fine, and it maximizes code sharing between the Driver wrapper and the XADataSource wrapper. It's certainly possible to move things around and get a new Connection from the XAConnection each time we make a new jca connection wrapper, but I don't see any advantage. We have to wrap whatever java.sql.Connection object we get from the vendor driver in order to support ManagedConnection.associateConnection. AFAIK there is no reason to support PooledConnection for non-xa drivers rather than getting connections directly from DriverManager. So, maybe I'm missing something, but I don't see you indicating what problem you are trying to solve or how changing this implementation would increase or improve jboss functionality. Do you know of any vendors that supply a ConnectionPoolDataSource? Do you know of any PooledConnection implementations that aren't XAConnections that provide any useful functionality beyond getting connections directly from DriverManager? Thanks david jencks > > -- > Igor Fedorenko > Think smart. Think automated. Think Dynamics. > www.thinkdynamics.com > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
