[
https://issues.apache.org/jira/browse/DERBY-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12601032#action_12601032
]
Knut Anders Hatlen commented on DERBY-48:
-----------------------------------------
Thanks Dag. Some more comments:
- I can't find the test case in the patch. Did you forget svn add?
- I agree that we probably shouldn't check for LOCK_TIMEOUT_LOG and DEADLOCK
(Although I'm not sure the statement that retrying in the outer transaction
usually causes a new deadlock is correct, since aborting the nested transaction
probably would allow the other transactions involved in the deadlock to
continue.)
- In the code below, if we move destroy() out of the try block (which we could
and perhaps should?), it becomes obvious that the potentially swallowed
exception is an error in commit. This I think would mean that we haven't
actually created the schema, and it feels a bit strange to ignore that
exception, even in insane builds. I think it would make sense to revert this
back to how it was in patch 1 and 2, where exceptions from nestedTc.commit()
were not swallowed.
+ try {
+ nestedTc.commit();
+ nestedTc.destroy();
+ } catch (StandardException e) {
+ if (SanityManager.DEBUG) {
+ // Should not happen
+ throw e;
+ }
+ }
> A connection request that has a default schema that is being created by
> another transaction will fail to connect
> -----------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-48
> URL: https://issues.apache.org/jira/browse/DERBY-48
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.0.2.2, 10.1.1.0
> Reporter: Kathey Marsden
> Assignee: Dag H. Wanvik
> Attachments: derby-48-1.diff, derby-48-1.stat, derby-48-2.diff,
> derby-48-2.stat, derby-48-3.diff, derby-48-3.stat, derby-48-4.diff,
> derby-48-4.stat, LazyDefaultSchemaCreationTest.java
>
>
> 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.
> This is a problem in particular for a prepared XA transaction, where even
> after restarting the system, the user cannot reconnect and recover the
> transaction.
> Here is the reproduction in ij.
> java -Dij.exceptionTrace=true -Dij.protocol=jdbc:derby: -Dij.user=me
> -Dij.password=pw org.apache.derby.tools.ij
> ij version 10.0 (C) Copyright IBM Corp. 1997, 2004.
> ij> connect 'testdb;create=true';
> ij> autocommit off;
> ij> create table mytabi(i int);
> 0 rows inserted/updated/deleted
> ij> connect 'testdb';
> ERROR 40XL1: A lock could not be obtained within the time requestedERROR
> 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:329)
> 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:115)
> 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:7118)
> at
> org.apache.derby.impl.sql.catalog.DataDictionaryImpl.locateSchemaRow(DataDictionaryImpl.java:1381)
> at
> org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getSchemaDescriptor(DataDictionaryImpl.java:1291)
> at
> org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.initDefaultSchemaDescriptor(GenericLanguageCon
> at
> org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.initialize(GenericLanguageConnectionContext.ja
> at
> org.apache.derby.impl.db.BasicDatabase.setupConnection(BasicDatabase.java:267)
> at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.startTransaction(TransactionResourceImpl.java:182)
> 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 java.sql.DriverManager.getConnection(DriverManager.java:512)
> at java.sql.DriverManager.getConnection(DriverManager.java:140)
> at org.apache.derby.impl.tools.ij.ij.dynamicConnection(ij.java:843)
> at org.apache.derby.impl.tools.ij.ij.ConnectStatement(ij.java:700)
> at org.apache.derby.impl.tools.ij.ij.ijStatement(ij.java:528)
> at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:283)
> at org.apache.derby.impl.tools.ij.Main.go(Main.java:204)
> at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:170)
> at org.apache.derby.impl.tools.ij.Main14.main(Main14.java:50)
> at org.apache.derby.tools.ij.main(ij.java:54)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
