Thanks Peter and Berin for your suggestions. I look at my code where I use the db pooling and see if I can spot some offense. I'll post back with what I find.
"Berin Loritsch" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Peter Donald wrote: > > On Fri, 6 Jun 2003 12:41 am, Timothy Bennett wrote: > > > >>I recently added the DataSourceSelector block to my Phoenix application, > >>and now my Phoenix no longer shuts down cleanly. > > > > > > The problem is that DataSourceComponent objects are hanging. Unfortunately it > > is difficult to determine where exactly it is but I am willing to bet it is a > > deadlock in the pooling layer. I would recomend you move to a better tested > > and supported db pool such as > > > > http://jakarta.apache.org/commons/dbcp/ > > > > > The only thing that I am aware of that would cause DataSourceComponent > to lock is not closing connections you get from it. > > JdbcDataSourceComponent uses a hard limiting pool, as our users wanted. > That means that the pool will wait for a Connection object to be > released back to the pool. Connection objects are released when you > call the close() method. If all the connection objects are in use, > and none are ever released, then you will experience hanging. > > The proper way to do ANY JDBC work (whether you are using it directly, > or using a pooling code like DataSourceComponent or DBCP) is to ensure > a close in the finally block. Otherwise if an exception is thrown > your connection is never closed. > > For instance: > > Connection conn = null; > Statement stmt = null; > ResultSet result = null; > > try > { > conn = dataSource.getConnection(); > stmt = conn.createStatement(); > result = stmt.executeQuery("SELECT * FROM foo"); > > while (result.next()) > { > // do stuff > } > } > finally > { > if (null != result) try {result.close();} catch(Exception e){} > if (null != stmt) try {stmt.close();} catch(Exception e){} > if (null != conn) try {conn.close();} catch(Exception e){} > } > > > This protects you from ideosynchrasies in different vendor's JDBC > drivers. For instance, with Oracle you will run out of cursors if > you do not ensure your result sets and statements are closed, and > with pooling code your connection will never be returned to the pool > if that is not closed. > > > You will continue to see the blocking with DBCP if you have it > configured to have a hard limit on the number of connections. > That is a requirement if you only have so many connections allowed > to you (such as with Oracle, Informix, DB2, etc.). > > As to DBCP vs. Excalibur DataSource, they both work and are well > tested and used. Cocoon developers have been using Excalibur for a > couple years now. It is being actively supported, and if you find > a problem we will have a fix for you. > > BTW, another source of hanging might be the ThreadPool code used > in the Cornerstone ThreadManager which is used by Cornerstone > Scheduler. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
