Thanks Steffen, that did the trick!
-----Urspr�ngliche Nachricht----- Von: Schlachter, Steffen (LDS) [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 17. Juni 2003 16:43 An: [EMAIL PROTECTED] Betreff: Re: [castor-dev] multithreaded environment with CastorJDO / Connection pooling with PoolMan Jens, I am working on similar things at the moment and I think that I may have an answer to your second question: Apparently Castor JDO does not open or close connections on getConnection or close. Instead it opens the connection when you execute a statment and it won't close it before you close the ResultSet (i.e. call results.close() when you're finished with the processing). That works for me. Hope this is of any help. Steffen Hi everybody, I'm developing a client-server application: a standalone server component as backend and a smaller client application in form of a j2ee webclient (JSPs/Servlets). Both components are communication via RMI-IIOP. The backend component is also handling data persistence - that's where castor JDO is used. I use a MySQL 4.0 DB and the latest version of PoolMan to pool DB connections. Castor version is 0.9.4.1 A) A question about design/code: In general each subcomponent of the backend gets the JDO factory object so when they need a Database connection object the simply call jdo.getDatabase() , use the db object and when finished close the db connection: Database db = null; try { db = jdo.getDatabase(); db.begin(); // ... do something ... } } catch (PersistenceException e) { logger.error("encountered exception ...", e); } finally { try { db.commit(); db.close(); } catch (TransactionNotInProgressException e) { logger.error("encountered exception ...", e); } catch (TransactionAbortedException e) { logger.error("encountered exception ...", e); } catch (PersistenceException e) { logger.error("encountered exception ...", e); } } I am encountering several problems concering thread savety and the db connections. As you can see the commit() and the close() methods are called in the finally block to ensure connections are closed and given back to the poolman's pool. It this technique OK in general? The application is multithreaded since the webfrontend (client) runs on an a Tomcat 4.1 server. Do you have enhancement suggestions ? B) Occuring exceptions: With the code stated about (which is used in lots of different implementations) I receive exceptions after some time, like: java.sql.SQLException: Connection.close() has already been called. Invalid operation in this state. at com.mysql.jdbc.Connection.getMutex(Unknown Source) at com.mysql.jdbc.PreparedStatement.executeQuery(Unknown Source) at com.codestudio.sql.PoolManPreparedStatement.executeQuery(Unknown Source) at org.exolab.castor.jdo.engine.SQLEngine$SQLQuery.execute(Unknown Source) at org.exolab.castor.persist.TransactionContext.query(Unknown Source) at org.exolab.castor.jdo.engine.OQLQueryImpl.execute(Unknown Source) at org.exolab.castor.jdo.engine.OQLQueryImpl.execute(Unknown Source) ... or org.exolab.castor.jdo.PersistenceException: This thread is already associated with a transaction in progress at org.exolab.castor.jdo.engine.DatabaseImpl.begin(Unknown Source) ... For me it seems that some connections aren't closed/returned. When using the debug option for PoolMan I get some output like: PoolMan ObjectPool metrics after returning object: 2003-06-17 14:04:58,460 DEBUG [pcePool] : PoolMan ObjectPool metrics after returning object: Pool Name: pcePool { Total Objects: 1 Objects Available: 1 Objects In Use: 0 } 2003-06-17 14:04:58,460 DEBUG [pcePool] : Pool Name: pcePool { Total Objects: 1 Objects Available: 1 Objects In Use: 0 } Initially I have 5 Objects in Total and Available. As you can see they have decreased to 1. But why? Perhaps I misunderstand it but in my understanding poolman objects like above are database connections in the pool, aren't they ? I am quite confused with the wording to be honest. Please give me a hint =) Cheers, Jens ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
