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 <[email protected]
> 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
>
>
