So, in case anybody is interested in this, the problem seems to be GlassFish in this case. When neither a global nor a local transaction is started, when the connection is closed and returned to the pool (using their wrapper ManagedConnection), the following code is called at some point:

private void resetAutoCommit() throws ResourceException {
        if (defaultAutoCommitValue != getLastAutoCommitValue() && !(isTransactionInProgress())) {
            try {
            } catch (SQLException sqle) {
                String i18nMsg = localStrings.getString(
                throw new ResourceException(i18nMsg + sqle.getMessage(), sqle);

For some reason, the connection is thought to be using JTA (although I never really start the tx), isTransactionInProgress returns false, and the autoCommit is set - which results in the local transaction that was implicitly started being committed. That's why I never see any Derby exceptions. I will ask the GF team about it, because this seems strange.


On Mon, Feb 18, 2013 at 5:29 PM, Bryan Pendleton <> wrote:
> One more question, though: the uncommitted insert comes up
> in the subsequent select - is this data coming from the server,
> from the active tx, or does the jdbc driver cache the data somehow?

The results are coming from the server. The server shows you your own
uncommitted updates, but won't show them to any other transaction
until you commit or abort your transaction.

To be precise, some of these behaviors are controllable: see the
discussion of "isolation" in the docs: