| Subject | Re: [IBO] "lock conflict on no wait transaction deadlock" |
|---|---|
| Author | Helen Borrie |
| Post date | 2003-02-21T22:17:12Z |
At 02:54 PM 21/02/2003 +0000, you wrote:
is in a different transaction from the statement which you are submitting
to update the table. This is OK; but the listview's ib_cursor will need
to be able to see the committed work from the other statement. Broadly,
before you try to re-read the ib_cursor's dataset, its transaction will
need to be either 1) committed and requeried or 2) set with an isolation
level of tiReadCommitted.
1) is preferable, since there is no reason to hold the ib_cursor open once
you have fetched all of its data.
Timing is of the essence here. You want the ib_cursor's transaction to be
committed *before* you execute the statement in the other transaction; and
you want the statement's transaction to be committed before you requery the
ib_cursor. If you would like to add some automation to the resynching of
the listview's cursor, think about using DMLCaching.
Don't use autocommit on the ib_cursor's transaction, since this performs
only a commitretaining (which restarts the transaction). You need a hard
commit here and to revive the cursor's transaction when you are ready to.
NB - rollback on the ib_cursor's transaction would work, too, but commit is
less costly in resources...
Helen
>I've been working on this for the past 3 hours and I'm going round inIt sounds as if the ib_cursor which you are using to populate the listview
>circles.
>
>1. I have a TListView displaying records, populated by a cursor.
>
>2. I add a new record via a dialog.
>
>3. The TListView form tries to display this new record but gets the
>above lock conflict.
>
>4. Thereafter, whenever I try to populate the TListView I get the
>above lock conflict.
>
>I've used the TIB_MonitorDialog to confirm that the dialog is
>correctly commiting the new record and I can see the record(s) in
>Interbase Workshop.
>
>I've performed a few sweeps on the database and even rebooted the
>machine (it's a local db using 'localhost') but I still get the above
>error when trying to populate the TListView.
>
>After a reboot, simply trying to get the contents of the table causes
>the conflict. I call cursor->First() and pow! conflict.
>
>Any pointers to what I can try?
is in a different transaction from the statement which you are submitting
to update the table. This is OK; but the listview's ib_cursor will need
to be able to see the committed work from the other statement. Broadly,
before you try to re-read the ib_cursor's dataset, its transaction will
need to be either 1) committed and requeried or 2) set with an isolation
level of tiReadCommitted.
1) is preferable, since there is no reason to hold the ib_cursor open once
you have fetched all of its data.
Timing is of the essence here. You want the ib_cursor's transaction to be
committed *before* you execute the statement in the other transaction; and
you want the statement's transaction to be committed before you requery the
ib_cursor. If you would like to add some automation to the resynching of
the listview's cursor, think about using DMLCaching.
Don't use autocommit on the ib_cursor's transaction, since this performs
only a commitretaining (which restarts the transaction). You need a hard
commit here and to revive the cursor's transaction when you are ready to.
NB - rollback on the ib_cursor's transaction would work, too, but commit is
less costly in resources...
Helen