You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Kathey Marsden <km...@Sourcery.Org> on 2004/10/20 23:43:21 UTC
Problem closing statement after xa_end
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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?
Thanks
Kathey
Here is the trace:
A lock could not be obtained within the time requested
ERROR 40XL1: A lock could not be obtained within the time requested
at
org.apache.derby.iapi.error.StandardException.newException(StandardException.java:295)
at
org.apache.derby.impl.services.locks.LockSet.lockObject(LockSet.java:408)
at
org.apache.derby.impl.services.locks.SinglePool.lockAnObject(SinglePool.java:168)
at
org.apache.derby.impl.services.locks.SinglePool.lockObject(SinglePool.java:220)
at
org.apache.derby.impl.store.raw.xact.RowLocking3.lockRecordForRead(RowLocking3.java:181)
at
org.apache.derby.impl.store.access.heap.HeapController.lockRow(HeapController.java:425)
at
org.apache.derby.impl.store.access.heap.HeapController.lockRow(HeapController.java:543)
at
org.apache.derby.impl.store.access.btree.index.B2IRowLocking3.lockRowOnPage(B2IRowLocking3.java:32
at
org.apache.derby.impl.store.access.btree.index.B2IRowLocking3._lockScanRow(B2IRowLocking3.java:571
at
org.apache.derby.impl.store.access.btree.index.B2IRowLockingRR.lockScanRow(B2IRowLockingRR.java:11
at
org.apache.derby.impl.store.access.btree.BTreeForwardScan.fetchRows(BTreeForwardScan.java:374)
at
org.apache.derby.impl.store.access.btree.BTreeScan.next(BTreeScan.java:1691)
at
org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getDescriptorViaIndex(DataDictionaryImpl.java
at
org.apache.derby.impl.sql.catalog.DataDictionaryImpl.locateSchemaRow(DataDictionaryImpl.java:1381)
at
org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getSchemaDescriptor(DataDictionaryImpl.java:1
at
org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.initDefaultSchemaDescriptor(Generi
at
org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.initialize(GenericLanguageConnecti
at
org.apache.derby.impl.db.BasicDatabase.setupConnection(BasicDatabase.java:267)
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.startTransaction(TransactionResourceImpl.java:1
at
org.apache.derby.impl.jdbc.EmbedConnection.<init>(EmbedConnection.java:237)
at
org.apache.derby.impl.jdbc.EmbedConnection20.<init>(EmbedConnection20.java:49)
at
org.apache.derby.impl.jdbc.EmbedConnection30.<init>(EmbedConnection30.java:56)
at
org.apache.derby.jdbc.Driver30.getNewEmbedConnection(Driver30.java:68)
at org.apache.derby.jdbc.Driver169.connect(Driver169.java:172)
at
org.apache.derby.jdbc.EmbeddedDataSource.getConnection(EmbeddedDataSource.java:458)
at
org.apache.derby.jdbc.EmbedPooledConnection.openRealConnection(EmbedPooledConnection.java:139)
at
org.apache.derby.jdbc.EmbedXAConnection.getRealConnection(EmbedXAConnection.java:814)
at
org.apache.derby.jdbc.XAStatementControl.getRealStatement(XAStatementControl.java:80)
at
org.apache.derby.iapi.jdbc.BrokeredStatement.getStatement(BrokeredStatement.java:507)
at
org.apache.derby.iapi.jdbc.BrokeredStatement.close(BrokeredStatement.java:123)
at TestXA.main(TestXA.java:58)
$
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBdtv5G0h36bFmkocRAuNyAJ0Yyixa25SxmqNQPqNuJbBwdMA/owCeKRGq
3xMdVNtGuCQkP6EmOstPuos=
=QH5q
-----END PGP SIGNATURE-----
Re: Problem closing statement after xa_end
Posted by Kathey Marsden <km...@Sourcery.Org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Daniel John Debrunner wrote:
> 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.
I think that would be particularly helpful in the case of XA
transactions, since even after shutting down and restarting the system,
the user cannot reconnect to recover the transaction because of the
lock. I'll file a bug.
Thanks
Kathey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBd+JqG0h36bFmkocRAvLRAJ9P6bpL5fhWZg1zUPy2iFjU8L0u/gCeIaUo
I+ofts95eJsVehWgI5BE2Vc=
=EcTq
-----END PGP SIGNATURE-----
Re: Problem closing statement after xa_end
Posted by Daniel John Debrunner <dj...@debrunners.com>.
-----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-----