I think I may have a better clue as to what is going on. As I stated in my initial post, I have two SARs deployed in my Phoenix: (1) the avalon-hsql.sar and (2) myapp.sar. The hsqldb block is started first and it uses a ConnectionManager I believe to manage connections to its database. Then myapp is started an I have a block that uses the DataSourceSelector to make pooled connections to the database.
When I shutdown Phoenix, it shuts down the hsqldb block first, and as the ConnectionManager is going through disposable it "seems" to barf. I say "seems" because there really isn't a stack dump that is really informative. Here's the lines from the phoenix.log file when Phoenix shutdown starts: INFO 2003-06-07 17:08:57.706 [Phoenix.] (): 5 Blocks to process for phase "shutdown". Order of processing = [hsql-server, connections, scheduler, thread-manager, sockets]. DEBUG 2003-06-07 17:08:57.706 [Phoenix.] (): Processing Block named "hsql-server" through phase "shutdown". DEBUG 2003-06-07 17:08:57.706 [Phoenix.] (): Component named "hsql-server" is passing through the Destruction stage. DEBUG 2003-06-07 17:08:57.706 [Phoenix.] (): Processed Block named "hsql-server" through phase "shutdown". DEBUG 2003-06-07 17:08:57.706 [Phoenix.] (): Processing Block named "connections" through phase "shutdown". DEBUG 2003-06-07 17:08:57.706 [Phoenix.] (): Component named "connections" is passing through the Disposing stage. At this point, depending on which Phoenix kernel I'm running (default or beanshell), different things are spooled to System.out. What seems to be that is happening is that the ConnectionManager in hsqldb is being disposed, but my block in myapp.sar has been killed yet, and its DataSourceSelector still has pooled connections to the database active. Could this be the possible problem? If so, this really is good ammunition for a way to describe to Phoenix which SARs should be loaded and unloaded in what order. "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]
