Subject Re: Lock conflict
Author dirinler
--- In, Helen Borrie <helebor@...>
> At 11:20 PM 16/06/2008, you wrote:
> >Hi there ,
> >
> >fb 2.1
> >
> >we have a program it works as server / problem is when i
> >in edit(append or insert) mode in the database if another user
> >be in edit(or append or insert) it says Lock conflict .....
> This is not a problem: it is concurrency in action. Your
application should intercept lock conflicts and deliver a message
and a way to deal with them.
> >the program gives this information even the users are not on the
same record? im confused about this error.
> You will be less confused when you understand that updating,
inserting and deleting occur in two stages: until the transaction
is committed, changes or deletions are visible only to the
transaction that performed them; changed or deleted records are
locked and will remain so until the transaction is either committed
or rolled back.
> If another transaction is In snapshot isolation ("concurrency") or
in all settings except one for read committed isolation, there is
still a lock conflict after the commit if that other transaction
started *after* the transaction that had the lock.
> >is there a solution?
> Repeat, a lock conflict is not a problem. It happens
intentionally, to prevent transactions from overwriting the work of
other transactions. The "solution" is have your application handle
concurrency properly. You really need to understand how transaction
isolation works, along with the various other settings you can apply
(WAIT/NO WAIT lock resolution, [NO] RECORD_VERSION for Read
Committed) and handle each possible type of lock conflict
appropriately in your application code.
> >i set the transactions after insert or append but at least it
gives this information.
> "set the transactions"? What does this mean?
> By the way, "append" is not a Firebird concept. In Firebird,
INSERT always appends rows to a table. There is no APPEND statement.
> ./heLen

Thanks for your answer Helen ,

i meant the i set the transaction CommitRetaining as default action
on my program.the transaction's setting is read_committed
rec_version nowait and append and insert are same things as
practically on my program.yes you are right actually its not a
problem but the problem is the users arenot on the same record at
least the transaction gives this information.and i manage this
status if users are on the same record(insert or edit mode) i send
them an message i still catch this state but i mean they are not on
the same record and if they insert a record after insert the
transaction commit itself.