Subject Re: Deadlock in a select statement
Author jensdein
Thanks a lot!!

Allready implemented and in test - I hope this solves my problem.

Jens Dein

--- In, Helen Borrie <helebor@t...>
> At 07:47 AM 23/09/2004 +0000, you wrote:
> >Hi,
> >
> >I have a problem that has been bugging me for a while now. In my
> >transaction I use a Cuncurrency locking isolation. I try to make
> >that changes are committed on a regular basis.
> >
> >Somehow my users a sometimes getting a deadlock situation on a pure
> >select statement (no updates, just read only) using Committed
> >isolation.
> >
> >How is that possible? I thought I shoulden't be getting a deadlock
> >a select statement - only on changes!!
> If your ReadCommitted transaction is configured with NO WAIT locking
and NO
> RECORD VERSION, then any older transaction that has an update
pending will
> cause a lock conflict (erroneously delivered to you as a deadlock
> if your SELECT requests rows that, if committed by the other
> would change state.
> >Hov do I eventaully resolve what caused the lock?
> To quote Ann Harrison, in response to a real-life problem yesterday,
> similar to your own:
> "If "record_version" is set, then the select procedure should be
> able to ignore uncommitted records."
> >PS.
> >Using FB 1.5 and IBObjects for connectivity - if that is of any
> >importance.
> Your tiReadCommitted transaction should be configured with either
> True, or with LockWait false and RecVersion true.
> ./heLen