On Monday, May 13, 2013 4:10:25 PM UTC+2, Noel Grandin wrote:
>
>
> I'm not denigrating your code, I'm simply stating a fact
> - switching to an in-memory database like H2 will accelerate things by
> an order of magnitude and expose bugs that have long been lying hidden.
> Happens to me all the time.
>
Yes, but this can be true only in multi-threaded environments, where
concurrency and timing issues can make the difference. If you have an only
thread that always does the same things sequentially, it's rather strange
that speed by itself can change the actual result, isn't it?
> I suggest you start by putting a tracepoint at
> JdbcXAConnection.PooledJdbcConnection#close()
> Something like
> new Throwable().printStackTrace()
> works well for me in identifying where the errant call is coming from.
>
Since we wrap XAConnections, we may try to add a ConnectionEventListener to
the connection returned by javax.sql.PooledConnection.getConnection() to
listen to connectionClosed events. Otherwise I can't think of a way to set
a tracepoint like the one you said without recompiling H2.
It will be quite hard, however, to gather useful information, since the log
output may risk to fill up our hard drive... in our example, the close
method will certainly be called countless times before hitting the problem.
Anyway, swallowing exceptions like this:
public synchronized void close() throws SQLException {
if (!isClosed) {
try {
rollback();
setAutoCommit(true);
} catch (SQLException e) {
// ignore
}
closedHandle();
isClosed = true;
}
}
actually doesn't help in these situations! ;-)
Mauro Molinari
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/h2-database?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
