On 8/15/06, Mike Matrigali <[EMAIL PROTECTED]> wrote:
Yip Ng (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/DERBY-1621?page=all ]
>
> Yip Ng updated DERBY-1621:
> --------------------------
>
> Attachment: derby1621trunkstat03.txt
> derby1621trunkdiff03.txt
>
> Attaching patch derby1621trunkdiff03.txt, this patch adds a new overloaded open method with a wait option in RowChanger interface and implements it in RowChangerImpl.java.
>
> After investigating abit, I realized that TransactionController.OPENMODE_LOCK_NOWAIT option only applies to table or table intent locks and not row locks which explains why in some scenarios the recompilation for the nested transaction is still waiting for a lock. e.g.:
>
> ...
> create unique index tu on t2(i);
> create trigger tt after insert on t1 for each statement mode db2sql insert into t2 values 1;
> autocommit off;
> -- invalidates the trigger since it depends on tu
> drop index tu; <=== got a S row lock on one of the SYSDEPENDS row.
> insert into t1 values 1; <=== waiting for X row lock on one of the SYSDEPENDS row
> with the nested transaction... not what we want...
> ...
>
> Is there a way to provide NOWAIT on fetch operation to the store currentl
No way to provide NOWAIT, other than at open time. if it existed, what
would you do? You would get a lock timeout from the insert, is that ok?
Can you explain a little more what is going on in the nested
transaction. Does the recompile of the trigger in the insert require
write locks?
