Your version has the same effect. Thanks for updating the source.

I have a separate question about the FBManagedConnection and the
FBPoolingConnectionManager. The FBPoolingConnectionManager calls
FBManagedConnection.addConnectionEventListener for every connection.
The pooling manger needs to do this so it can detect closed connections.

However - the FBManagedConnection.notify method gets called for
transaction start, commit and rollback. In a non-managed environment
there is a lot of unnecessary processing to support the pooled
connections. The notify clones an ArrayList and allocated a
ConnectionEvent object.

Do you see any advantage in using a separate notify interface for closed
connections in the FBPoolingConnectionManager? It would reduce the
overhead of cloning the list and allocating the connection event objects
within the notify when they are not needed.

The current design is nice because everything takes the same path. A
separate notify interface would help improve performance for the "simple
tests" that are often posted to this thread.

My stats for this call are: 1 delete, 2000 insets, 1 select in
manual-commit mode - but I committed after every transaction anyway.
4007 calls to notify which allocated 16K blocks for a total of 362K of
memory.