db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-48) A connection request that has a default schema that is being created by another transaction will fail to connect
Date Fri, 30 May 2008 14:34:45 GMT

    [ 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.


Mime
View raw message