Hello, On Tue, Aug 16, 2011 at 3:47 PM, Jeremy Evans <[email protected]>wrote:
> On Aug 16, 11:25 am, Bill Burton <[email protected]> wrote: > > Hello, > > > > Have you tried configuring access to DBCP via JNDI? Think that should > allow > > you to configure DBCP the way you want in Tomcat and Sequel only needs > the > > JNDI connection. > > > > For JDBC in general, there are multiple connection pool implementations. > > Apache DBCP is just one. c3po (http://sourceforge.net/projects/c3p0/) > is > > another. > > > > If connecting to an Oracle database, there's a connection pool > > implementation that can be accessed within the JDBC driver by specifying > a > > different driver class. Newer versions of the Oracle driver have > separated > > this functionality out into their Universal Connection Pool (UCP) feature > > which is a separately installable jar file. > > > > If there is some way of configuring a generic JDBC driver with custom > > parameters within Sequel, it would be possible to support most any kind > of > > connection pool since they would support JDBC as an interface. > > Note that that having a connection pool class internal to the > connection object that Sequel uses is not wise. The connection object > that Sequel uses should represent a single database connection. If it > doesn't, all sorts of problems could occur. For example, > Database#transaction would not function correctly unless the same > database connection was used for all statements inside the > transaction. > As far as I know, this shouldn't be an issue as when a connection is made at the application level, the pool allocates or creates a connection which is dedicated as long as the application (or its thread) keeps it open. When the application closes the connection, it is returned to the pool for reuse instead of actually closing it. Once an application is given a connection, there's no switching around of connections mid-stream so using transactions works the same way as in a non-pooled environment. The only reason third-party JDBC connection pools like DBCP and c3p0 are even possible, is that they maintain semantics consistent with a real JDBC driver in terms of the way connections work. These pools are configured like a regular JDBC driver but have many more parameters to support configuring the actual supporting JDBC driver along with all the parameters for managing the connection pool. Because these pool implementations are generic JDBC drivers that delegate to a real JDBC driver, they generally will support a way of mapping data types from the underlying JDBC driver by configuring parameters. So for Sequel to support JDBC connection pools is really just a matter of supporting the configuration of a generic JDBC driver where the driver class and parameters all need to be specified explicitly. It could be helpful to support a couple of connection pools explicitly but the effort would probably be better spent documenting how to configure generic JDBC support to work with one of the connection pools such as DBCP that's rather commonly used. -Bill -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en.
