[
https://issues.apache.org/jira/browse/DERBY-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12601153#action_12601153
]
Knut Anders Hatlen commented on DERBY-48:
-----------------------------------------
The last patch looks fine.
Some small nits in the test, but they shouldn't stop you from committing.
- In a comment near the end of testDerby48testNewSchemaHang: s/shoudl/should
- In testDerby48testNewSchemaHang:
+ } catch (SQLException e) {
+ if (e.getSQLState().equals(LOCK_TIMEOUT)) {
+ c1.rollback();
+ c1.close();
+ fail("DERBY-48 still seen");
+ } else {
+ throw e;
+ }
Why not just let the SQLException be thrown out of the test method regardless
of the SQL state? As it is now, we'll lose the stack trace if it's a lock
timeout.
- The last part of testDerby48testNewSchemaHang tests that the implicitly
created schema is still around after a rollback. It's maybe OK to test it, but
it's not actually testing whether or not Derby does the right thing, it only
canonizes the current behaviour. But I guess that's what many of our tests do
anyway...
- Is it intentional that derby.locks.waitTimeout is set to 1 both in setUp()
and in testDerby48SelfLockingRecoveryDeadlockDetectionOn()?
- waitTimeout is not reset, as far as I can see. I think it would be better to
wrap the test with DatabasePropertyTestSetup.setLockTimeouts() which
automatically does the right thing for you. DatabasePropertyTestSetup would
probably also be the most appropriate way to set reset the deadlockTrace
property.
- In tearDown() we have this code:
+ try {
+ createStatement().executeUpdate("drop schema newuser restrict");
+ } catch (SQLException e) {
+ }
Perhaps you could add a comment about why the exception is swallowed. Is it
because the schema in some cases does not exist? In that case, perhaps we
should have an assertSQLState() to prevent unexpected exceptions from being
ignored?
- Is engine the right package for the test? We are also testing the client, it
seems.
> 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, derby-48-5.diff, derby-48-5.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.
