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
