I think I have this fixed here, by taking the DBMS connection pooling out of the path to the database.
Since there isn't any good way for a hunk of DSpace code to tell the storage layer whether it wants pooling, I took the rather circuitous route of writing a minimal in-memory JNDI provider so that it could substitute for the one in Tomcat when running commandline tools. This only works if you configure DSpace to look for a DataSource in JNDI. Since adding the provider and some supporting hacks in bin/dspace, I haven't seen any more crashes from this condition. I'm trying to get the provider into a distributable condition. We really do need to do *something* different in commandline tools. Right now they use the same DBMS connection configuration as the server, so if you set up for a pool of 100 connections then 'bin/dspace foo' will set up for its own pool of 100 connections when it starts. We probably don't want that in single-session applications. -- Mark H. Wood, Lead System Programmer [email protected] Asking whether markets are efficient is like asking whether people are smart.
pgpv4jdUXV1jc.pgp
Description: PGP signature
------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
