[I meant to send this to the list. Sorry about spamming you twice, Bill] [Apologies in advance if this turns up again later - my first attempt is still being retried] On Thu, Mar 29, 2001 at 12:08:04PM -0500, Bill Burke wrote: > One more thing on this that I've commented on before. > > The Oracle 8.1.7 drivers do connection and statement pooling as well > as XAConnections, so there is no need to use Minerva. > Unfortunately, Minerva does all the work of hooking up the > XAResources with the Transaction Manager and such. It would be > nice if there was some XADataSourceLoader framework so that > developers could write optimized driver specific datasources that > can connect up to JBoss's connection manager and be their own > connection pool. Am I making any sense here? Not to me. Connection pooling is a "quality of service" (terminology from the JCA spec) that is the responsibility of the application server. I can't see why you would want to burden a JDBC driver with this functionality. The XAConnection (extends PooledConnection) stuff is to faciliate the application server's connection pooling by allowing the JDBC driver to be aware of it (rough and hand-wavy, I know). If, however, you really want your connection pooling to be provided by the JDBC driver, the JCA provides a mechanism for you to do this. In the JCA, all of the "quality of services" (qualities of service?) are provided by a connection manager (implements javax.resource.spi.ConnectionManager). So, you could write your own connection manager that delegates pooling to the JDBC driver. You can do this now and plug it into JBossCX. See the examples in jboss.jcml, the JBossCX source and the Minerva source for examples on how this could be done. > Anyways, I'm very interested in putting together this simple > "framework" and writing an Oracle 8.1.7 specific JBoss DataSource, > and, if you want I would also clean up the JDBCProvider stuff you > talked about. Let me know. The XADataSourceLoader stuff is destined for obsolescence. It will all be done through JBossCX at some point in the future (after the deployment issues are sorted out). > Bill > > P.S. I know I'm new here, and there's a trust factor involved, but > I'm serious about contributing to any JBoss effort. In my experience, the best way to get trust is to just go ahead and code something that works. Toby. _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
