db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: [Derby-359]Skipping over user inserted values into GENERATED BY DEFAULT identity columns....
Date Fri, 23 Dec 2005 16:41:18 GMT
Mamta Satoor wrote:
> I looked at Derby code and in fact, Derby does implement the SQL
> standard by doing the job of getting the generated value and updating
> the system table SYSCOLUMNS for the next generated value in a
> transaction of its own. But this does not happen in its own transaction
> when there are lock issues on the system table.
>  
> If we run the problem script that Satheesh has provided in JIRA for this
> bug with autocommit on, we will have the expected behavior of Derby
> consuming the generated value even if the insert fails for duplicate
> key. But if the same script is run with autocommit off, the create
> unique index sql puts a table lock on SYSCOLUMNS table. Next when the
> insert is run with a request for system to generate a value, Derby
> starts a new transaction in InsertResultSet.getSetAutoincrementValue at
> line 777. At line 794, it calls DataDictionary.getSetAutoincrementValue
> method to do the actual job of generating the value and updating the
> system table. But because the user(parent) transaction has table lock on
> SYSCOLUMNS, <snip>

The troubling item here is that you say create index is getting a table
lock on SYSCOLUMNS. Is a create index on another table by another
transaction going to cause the same issue?

Is it the create index or the create table that is leading to the lock
on SYSCOLUMNS?

Dan.


Mime
View raw message