Re: AW: locking problem when selecting data

situation. The central question is, why are there any locks held for nothing selected? Sometimes, a lock is held for the case where nothing was selected, to prevent the insertion of a new row that would have satisfied the criteria, had it been present at the time of the original select. That

Re: AW: locking problem when selecting data

Kasper, Kay wrote: Hi Stanley, over the weekend i produced a test case (see the attachement). During my tests I found out, that the not executed commit/rollback of the update statement seems to be a solution for my special situation. An other solution seems to be to change the lock level to

AW: locking problem when selecting data

Hi Stanley, over the weekend i produced a test case (see the attachement). During my tests I found out, that the not executed commit/rollback of the update statement seems to be a solution for my special situation. An other solution seems to be to change the lock level to read uncommitted for the

AW: locking problem when selecting data

Hi Mark, thanks for your answer. But why is there already a lock on the row. All outher statements have been committed or have not selected the row. So there should be no other lock. I use the standard row locking of Derby which is, as far as i know, TRANSACTION_READ_COMMITTED. Kay

Re: AW: locking problem when selecting data

Kasper, Kay wrote: thanks for your answer. But why is there already a lock on the row. All outher statements have been committed or have not selected the row. So there should be no other lock. I suspect that the update statement has left the row locked. In general you can't rely on a

Re: AW: locking problem when selecting data

thanks for your answer. But why is there already a lock on the row. You can find extensive information about Derby's locking behavior here: http://db.apache.org/derby/docs/10.2/devguide/cdevconcepts30291.html thanks, bryan