Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Received-SPF: pass (hermes.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
Message-ID: <41772DC4.5020002@debrunners.com>
Date: Wed, 20 Oct 2004 20:32:20 -0700
From: Daniel John Debrunner <djd@debrunners.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.4.1) Gecko/20031008
MIME-Version: 1.0
To: Derby Development <derby-dev@db.apache.org>
Subject: Re: Problem closing statement after xa_end
References: <4176DBF9.4020709@Sourcery.Org>
In-Reply-To: <4176DBF9.4020709@Sourcery.Org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kathey Marsden wrote:
> In Derby the default schema is a schema with the user name.
> But until you create a table that schema doesn't actually exist.
>
> In XA, a BrokeredStatement will try to create a new local connection if
> the statement is used outside of an xa  connection, even if it is just
> to close the statement. This causes a lock timeout trying to get the
> default schema if the xa transaction created the first table in the
> default (user) schema.
>
> For example, the following code causes a lock timeout on stmt.close().
> ...
>
>
> conn = xaConnection.getConnection();
> Statement stmt = conn.createStatement();
> xaResource.start(xid,XAResource.TMNOFLAGS);
> // creating the first table creates the default
> // schema which corresponds to the user
> stmt.executeUpdate("create table mytab (i int)");
> xaResource.end(xid,XAResource.TMSUCCESS);
> xaResource.prepare(xid);
>
> //Statement.close() tries to get the realConnection and finds it null so
> // tries to create a new one and times out looking for the default
> //schema descriptor. stmt.execute() etc. have the same problem
> stmt.close();
>
>
> Is this a bug or expected behaviour?

I would say one possible optimization and one bug.

optimization) A Statement.close() on a "disconnected" Statement object
is not optimised to be a no-op on Statement.close(). I can look into
this as I am looking at some consistency issues with closed statements
for pooled and XA connections.

bug) A connection request that has a default schema that is being
created by another transaction will block until that transaction
completes (or time out). Probably in this situation the connection
request should be succeed as if the schema does not exist.

Dan.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBdy3EIv0S4qsbfuQRArqJAKCE1mV6RqmvKM6aQpPI8nND+FnSAQCgr0P8
pM0e4FFjFvipSAwsOEFpo7E=
=TM4R
-----END PGP SIGNATURE-----