db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wujek Srujek <wujek.sru...@gmail.com>
Subject Re: Derby, JTA on GlassFish and very strange behavior
Date Tue, 19 Feb 2013 09:16:20 GMT
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

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

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 <bpendleton.derby@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

View raw message