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? -- 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
