Subject | Re: Lock conflict |
---|---|
Author | dirinler |
Post date | 2008-06-16T14:13:28Z |
--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...>
wrote:
and a way to deal with them.
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.
still a lock conflict after the commit if that other transaction
started *after* the transaction that had the lock.
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 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.
Thanks.
wrote:
>user
> At 11:20 PM 16/06/2008, you wrote:
> >Hi there ,
> >
> >fb 2.1
> >
> >we have a program it works as server /client.my problem is when i
> >in edit(append or insert) mode in the database if another userwantto
> >be in edit(or append or insert) it says Lock conflict .....application should intercept lock conflicts and deliver a message
>
> This is not a problem: it is concurrency in action. Your
and a way to deal with them.
>same record? im confused about this error.
> >the program gives this information even the users are not on the
>inserting and deleting occur in two stages: until the transaction
> You will be less confused when you understand that updating,
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.
>in all settings except one for read committed isolation, there is
> If another transaction is In snapshot isolation ("concurrency") or
still a lock conflict after the commit if that other transaction
started *after* the transaction that had the lock.
>intentionally, to prevent transactions from overwriting the work of
> >is there a solution?
>
> Repeat, a lock conflict is not a problem. It happens
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.
>gives this information.
> >i set the transactions after insert or append but at least it
>INSERT always appends rows to a table. There is no APPEND statement.
> "set the transactions"? What does this mean?
>
> By the way, "append" is not a Firebird concept. In Firebird,
>Thanks for your answer Helen ,
> ./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.
Thanks.