What is not clear is how this bug gets tripped: The generated SQL loads
and is accessible via the mysql command line, and my Flux authentication
is able to read from the database so I know JDBC is working, but when
I try to store an item, something goes wrong and I get a stacktrace.
The stacktrace is unimportant; what is important is the code section
that handles it in the Base*.save(String dbName) method. The block
reads like this:
DBConnection dbCon = null;
try
{
dbCon = BasePeer.beginTransaction(dbName);
save(dbCon);
}
catch(Exception e)
{
BasePeer.rollBackTransaction(dbCon);
throw e;
}
BasePeer.commitTransaction(dbCon);
If BasePeer.beginTransaction throws the exception (as it does in my
case) dbCon is still null, and that causes rollBackTransaction to
throw a NullPointerException at BasePeer.rollBackTransaction
(BasePeer.java:366) where it tests for transaction support with
dbCon.getConnection().getMetaData().supportsTransactions().
This masks the exception which caused the situation, so a quick-fix is
to add a Log.debug( e.getMessage()) call just before the call to
BasePeer.rollBackTransaction.
--
Gary Lawrence Murphy <[EMAIL PROTECTED]> TeleDynamics Communications Inc
Business Innovations Through Open Source Systems: http://www.teledyn.com
"Computers are useless. They can only give you answers."(Pablo Picasso)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
