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 { actualConnection.setAutoCommit(defaultAutoCommitValue); } catch (SQLException sqle) { String i18nMsg = localStrings.getString( "jdbc.error_during_setAutoCommit"); throw new ResourceException(i18nMsg + sqle.getMessage(), sqle); } setLastAutoCommitValue(defaultAutoCommitValue); } } 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. wujek On Mon, Feb 18, 2013 at 5:29 PM, Bryan Pendleton <bpendleton.de...@gmail.com > 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: > http://db.apache.org/derby/**docs/10.9/devguide/**cdevconcepts30291.html<http://db.apache.org/derby/docs/10.9/devguide/cdevconcepts30291.html> > > thanks, > > bryan > >