Hi,I'm running into a locking issue when using generated keys. My primary key column is defined as DATASTORE_IDENTITY BIGINT NOT NULL GENERATED ALWAYS AS IDENTITY. I don't care about the key being transactional. That is, if a transaction rolls back, I can live with the key that was allocated being
I thought Derby uses nested user transaction to commit generated
identity values, to avoid holding locks. See getSetAutoincrementValue()
in org/apache/derby/impl/sql/execute/InsertResultSet.java. I tried the
following using IJ, using default isolation levels. I couldn't
see the problem.
Sathe
I have not been able to reproduce this issue.
Derby uses nested internal transactions when updating the IDENTITY
column, it does not try to guarantee that a value won't be lost. These
locks should not be held until end of user transaction, they are
committed separate from the user transaction, so
To help debug this, try setting both derby.locks.monitor=true and
derby.locks.deadlockTrace=true . This will print the lock table dump
when the timeout or deadlock happens to derby.log. The lock table will
give information on what locks are being held etc..
Sunitha.
Mike Matrigali wrote:
I have not been able to reproduce this issue.
Derby uses nested internal transactions when updating the IDENTITY
column, it does not try to guarantee that a value won't be lost. These
locks should not be held until end of user transaction, they are
committed separate from the user transaction, so
