My code is a mix of DBCP with a bit of learning from PoolMan. Neither Avalon nor DBCP wrap all Statement and ResultSet interfaces and make sure it is impossible for them to be used after their Connection is returned to the pool. Avalon does nothing in that direction and DBCP is in this respect still a bit incomplete (or was when I forked).
This allows incorrect use to mess with the pool and the behavior of the Connections. It also makes it hard to implement a timeout policy for active Connection's, which sometimes is quite useful. Besides, I missed a bit more of control over the pace and the way the Pool grows and shrinks. (You only need to wrap the ResultSet for JDBC drivers incorrectly implemented. Closing the Statement should close the ResultSet.) As in Avalon and in DBCP, there is a separate generic pool that is used to implement the database pool. It also uses the standard DataSource and Connection interfaces. There is neither Statement nor ResultSet caching. In my experience ( <= read this as "with the stuff I do") I find no big performance gain in caching Statements and I believe that ResultSets should be cached elsewhere. Anyway, if you are looking for the ideal Database Pool implementations you should also take a look at PoolMan: http://www.codestudio.com/ It is LGPL and it is not perfect, but even when this is an obstacle you can always learn a lot from it. Have fun, Paulo Gaspar http://www.krankikom.de http://www.ruhronline.de > -----Original Message----- > From: Randy Speh [mailto:[EMAIL PROTECTED]] > Sent: Thursday, December 27, 2001 8:14 PM > > > Thanks for the info. Would you mind telling me the > differences between Avalon and Fulcrum/Commons. > > I just wasn't aware of Avalon for some reason. I've > been submerged in Turbine, Torque, Fulcrum and Commons > code. > > Thanks, > Randy > --- Berin Loritsch <[EMAIL PROTECTED]> wrote: > > Randy Speh wrote: > > > > > I would be very interested to see what your > > connection > > > pooling code looks like. I been trying to choose > > the > > > most appropriate connection pooling technique and > > have > > > been considering adapting one myself. Although, > > I'd > > > really rather use something from the open source > > > community. > > > > > > > > > Currently there is dbcp in Commons, Turbine > > connection pooling, > > and Avalon connection pooling. > > > > Both DBCP and Avalon provide similar semantics > > inspired by > > the official JDBC DataSource specifications--when > > you "close" > > the connection, it returns the Connection to the > > pool. Turbine > > (if I recall) makes you explicitly return it to the > > pool yourself. > > > > I won't get involved with which is the best pattern. > > > > Beyond that basic difference, there is alot of > > difference in the > > manner that the connection pools are configured. > > Since I don't > > have any real information on DBCP and Turbine > > pooling, I won't > > talk about them. Here is what Avalon's > > Configuration looks like: > > > > <connection> > > <pool-controller min="2" max="10" grow="2"> > > <keep-alive>SELECT 1 FROM DUAL</keep-alive> > > </pool-controller> > > > > <driver>oracle.jdbc.driver.OracleDriver</driver> > > > > <dburl>jdbc:oracle:thin:@localhost:1521:ORCL</dburl> > > <user>scott</user> > > <password>tiger</password> > > </connection> > > > > The Pool Controller specifies how many connections > > the pool starts > > with ("min"), the absolute maximum number of > > connections ("max"), > > and how many new connections it creates at a time > > when it needs > > more ("grow"). It is important to note that the > > maximum is absolute. > > The pool will not go beyond that maximum number. > > The reason being > > that some drivers have license restrictions and it > > helps the pool > > to not violate the license. The last part > > ("keep-alive") is the > > query used by the pool to determine if the > > connection has been closed > > by the server. We found out that not all databases > > are created > > equal, and while "SELECT 1" works for many > > databases, Oracle requires > > that "1" be selected from the dummy table "DUAL", > > and others like > > Informix require you to select from an application's > > table. > > > > You can determine for yourself if this is > > desirable--and possibly > > DBCP might steal ideas to narrow the differences. > > Who knows.... > > > > > > -- > > > > "They that give up essential liberty to obtain a > > little temporary safety > > deserve neither liberty nor safety." > > - Benjamin Franklin > > > > > > -- > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > > __________________________________________________ > Do You Yahoo!? > Send your FREE holiday greetings online! > http://greetings.yahoo.com > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
