[
https://issues.apache.org/jira/browse/DERBY-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600751#action_12600751
]
Knut Anders Hatlen commented on DERBY-48:
-----------------------------------------
Hi Dag,
The approach in the latest patch looks elegant. A couple of small comments and
questions:
- The try/catch around executeConstantAction() swallows all non-timeout
exceptions. I think we need to move "else throw se" from the inner if to the
outer if in the catch block.
- I think the code below is fine, but it would be clearer if the comment also
said: "In non-debug builds, we retry in the parent transaction before giving
up."
+ } catch
(StandardException e) {
+ if
(SanityManager.DEBUG) {
+ //
Should not happen
+ throw e;
+ }
+ }
- Not that it makes any difference in practice, but... When we call commit()
and destroy() on the nested transaction in the catch block, wouldn't it be more
natural to call abort()+destroy(), since we don't want any side effects of the
work performed by the nested transaction to be persisted? The javadoc for
TransactionController.destroy() says that it will also abort the transaction,
so I guess a call to destroy() would suffice.
- When we check for SQLState.LOCK_TIMEOUT, should we also check for
SQLState.LOCK_TIMEOUT_LOG, which is the message id used when lock tracing is
enabled? And should SQLState.DEADLOCK be handled the same way?
> 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,
> 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.
