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 "Dag H. Wanvik (JIRA)" <ji...@apache.org> on 2008/08/05 15:00:44 UTC
[jira] Issue Comment Edited: (DERBY-48) A connection request that
has a default schema that is being created by another transaction will fail
to connect
[ https://issues.apache.org/jira/browse/DERBY-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12619856#action_12619856 ]
dagw edited comment on DERBY-48 at 8/5/08 6:00 AM:
------------------------------------------------------------
It seems the SQL standard does not allow implicit
schema creation as in CREATE TABLE S.T(...), but Derby does.
I am starting to doubt whether the solution chosen in this patch is
good. If we want our DDL to be transactional, always creating implicit
schemas in separate transactions seems to defeat the
transactionality..
I can see four possibilities:
1) let the old behavior remain (essentially: "this is not a bug")
and roll back this patch
2) rework the patch to apply only for the initial default schema
Other implicit schema creations will happen in the user transaction as before.
3) drop the lazy schema creation, i.e. always create a user schema
as soon as a user (which has write access) connects
4) let the patch remain as is, impacting all implicit schema creation
and rewrite the release notes.
What do you think?
was (Author: dagw):
It seems the SQL standard does not allow implicit
schema creation as in CREATE TABLE S.T(...), but Derby does.
I am starting to doubt whether the solution chosen in this patch is
good. If we want our DDL to be transactional, always creating implicit
schemas in separate transactions seems to defeat the
transactionality..
I can see four possibilities:
1) let the old behavior remain (essentially: "this is not a bug")
and roll back this patch
2) rework the patch to apply only for the default schema
Other implicit schema creations will happen in the user transaction as before.
3) drop the lazy schema creation, i.e. always create a user schema
as soon as a user (which has write access) connects
4) let the patch remain as is, impacting all implicit schema creation
and rewrite the release notes.
What do you think?
> 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
> Fix For: 10.5.0.0
>
> 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, derby-48-6.diff, derby-48-6.stat, derby-48-7.diff, derby-48-7.stat, LazyDefaultSchemaCreationTest.java, releaseNote.html, releaseNote.html
>
>
> 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.