This one time, at band camp, Werner Guttmann said:
WG>
WG>Jens,
WG>
WG>have a look at your exception handling, especially the try/catch block where you
want to close the Database
WG>instance. If the commit() fails for one reason or another, your code to close the
Database instance will neevr
WG>execute.
WG>
WG>Imho, I'd move the commit() into the original try/catch block, as in (though
simplified)
WG>
WG>try {
WG> db.being();
WG>
WG> <your code>
WG>
WG> db.commit();
WG>}
WG>catch (Exception) {
WG>}
WG>finally {
WG> db.close();
WG>}
WG>
WG>IN addition, I'd consider to start using rollback() as well to maintain application
data integrity. If you encounter any
WG>(persistence related) exception, you might want to (try to) rollback the
transaction.
Werner assessment is correct.
In addition, I suggest reading the thread where Sylvie and I discussed
this topic back in November of 2002. I can't find a consistently linked
portion of this thread, but most of the posts within the thread can be
found here:
http://www.mail-archive.com/cgi-bin/htsearch?method=and&format=short&config=castor-dev_exolab_org&restrict=&exclude=&words=sylvie+threaded+bruce
One more thing, one of the exceptions you received seems to indicate that
you may be using nested transactions. Please note that Castor itself
does not support this. This would require a real transaction manager
(e.g. Tyrex). Please post more relevant code snippets for analysis.
You are wise to use Poolman as connection pooling can significantly
speed up the applications. However, the odd behavior you are receiving
definitely needs to be addressed.
Bruce
--
perl -e 'print unpack("u30","<0G)[EMAIL PROTECTED]&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
