Board index » delphi » deadlock update conflicts with concurrent update.

Forrest Lo

Delphi Developer
Tue, 07 Sep 2004 12:57:21 GMT

deadlock update conflicts with concurrent update.

Dear All,

I got the error message "deadlock update conflicts with concurrenct update'
when a client Post a record. It is no problem if only 1 user using the
program. However, the error will occur if there have more then 1 users using
the program. The cachedupdates = TRUE in tblCustomer (TIBTable).

procedure TfrmCustomer.btnSaveClick(Sender: TObject);
begin
  DM.tblCustomer.Post;
end;

procedure TDM.tblCustomerAfterPost(DataSet: TDataSet);
begin
  IBDatabase.ApplyUpdates([tblCustomer]);
  IBTransaction.CommitRetaining;
end;

Thanks & Best Regards,
Forrest

 
Craig Stuntz [TeamB

Delphi Developer
Tue, 07 Sep 2004 22:36:13 GMT

Re:deadlock update conflicts with concurrent update.


In article <3c9ab9af_1@dnews>, forr...@aliaspro.com says...

Quote

> I got the error message "deadlock update conflicts with concurrenct update'
> when a client Post a record. It is no problem if only 1 user using the
> program. However, the error will occur if there have more then 1 users using
> the program. The cachedupdates = TRUE in tblCustomer (TIBTable).

        This most likely means you have long-running, un-committed
transactions.  When a transaction changes a record, any further changes
to that record by other transactions will deadlock until the first
transaction commits.

        Generally speaking, you should commit after any change you want to
be visible to other users.

        HTH,

        -Craig

--
 Craig Stuntz (TeamB) Vertex Systems Corp. Columbus, OH
     Delphi/InterBase WebLog: http://delphi.weblogs.com
     InterBase PLANalyzer (Free IB optimization tool):
          http://delphi.weblogs.com/IBPLANalyzer

Forrest L

Delphi Developer
Wed, 08 Sep 2004 10:32:56 GMT

Re:deadlock update conflicts with concurrent update.


Hi Craig,

I found that IBTransaction.InTranscation is still TRUE after
IBDatabase.ApplyUpdates([TIBTable]) and IBTransaction.CommitRetaining. Why?

 Thanks & Best Regards,
Forrest

"Craig Stuntz [TeamB]" <cstuntz@no_spam.vertexsoftware.com> ???g??ls?D
:MPG.17050b6a85e440f1989...@newsgroups.borland.com...

Quote
> In article <3c9ab9af_1@dnews>, forr...@aliaspro.com says...

> > I got the error message "deadlock update conflicts with concurrenct
update'
> > when a client Post a record. It is no problem if only 1 user using the
> > program. However, the error will occur if there have more then 1 users
using
> > the program. The cachedupdates = TRUE in tblCustomer (TIBTable).

> This most likely means you have long-running, un-committed
> transactions.  When a transaction changes a record, any further changes
> to that record by other transactions will deadlock until the first
> transaction commits.

> Generally speaking, you should commit after any change you want to
> be visible to other users.

> HTH,

> -Craig

> --
>  Craig Stuntz (TeamB) ?Vertex Systems Corp. ?Columbus, OH
>      Delphi/InterBase WebLog: http://delphi.weblogs.com
>      InterBase PLANalyzer (Free IB optimization tool):
>           http://delphi.weblogs.com/IBPLANalyzer

Team

Delphi Developer
Wed, 08 Sep 2004 11:00:33 GMT

Re:deadlock update conflicts with concurrent update.


Quote
Forrest Lo wrote:

> Hi Craig,

> I found that IBTransaction.InTranscation is still TRUE after
> IBDatabase.ApplyUpdates([TIBTable]) and IBTransaction.CommitRetaining. Why?

Because CommitRetaining commits the transaction and leaves the current
transaction context active.  That is the difference between Commit and
CommitRetaining.

--
Jeff Overcash (TeamB)
      (Please do not email me directly unless  asked. Thank You)
This sad little lizard told me that he was a brontosaurus on his mother's
side.  I did not laugh; people who boast of ancestry often have little else
to sustain them.  Humoring them costs nothing and adds to happiness in
a world in which happiness is in short supply.   (RAH)

Forrest L

Delphi Developer
Wed, 08 Sep 2004 11:06:32 GMT

Re:deadlock update conflicts with concurrent update.


Hi, Craig,

So, Should I use Commit instead of CommitRetaining to prevent deadlock?

Thanks & Best Regards,
Forrest

"Jeff Overcash (TeamB)" <jeffoverc...@mindspring.com>
???????:3C9BEFD1.E4DE8...@mindspring.com...

Quote

> Forrest Lo wrote:

> > Hi Craig,

> > I found that IBTransaction.InTranscation is still TRUE after
> > IBDatabase.ApplyUpdates([TIBTable]) and IBTransaction.CommitRetaining.
Why?

> Because CommitRetaining commits the transaction and leaves the current
> transaction context active.  That is the difference between Commit and
> CommitRetaining.

> --
> Jeff Overcash (TeamB)
>       (Please do not email me directly unless  asked. Thank You)
> This sad little lizard told me that he was a brontosaurus on his mother's
> side.  I did not laugh; people who boast of ancestry often have little
else
> to sustain them.  Humoring them costs nothing and adds to happiness in
> a world in which happiness is in short supply.   (RAH)

Team

Delphi Developer
Wed, 08 Sep 2004 11:09:10 GMT

Re:deadlock update conflicts with concurrent update.


CommitRetaining should have no more affect on a deadlock than Commit.  No one
has ever presented a test case that shows this.  The only difference between the
two is commit ends the transaction, but CommitRetaining leaves the transaction
going from the commit point.

Quote
Forrest Lo wrote:

> Hi, Craig,

> So, Should I use Commit instead of CommitRetaining to prevent deadlock?

> Thanks & Best Regards,
> Forrest

--
Jeff Overcash (TeamB)
      (Please do not email me directly unless  asked. Thank You)
This sad little lizard told me that he was a brontosaurus on his mother's
side.  I did not laugh; people who boast of ancestry often have little else
to sustain them.  Humoring them costs nothing and adds to happiness in
a world in which happiness is in short supply.   (RAH)
Forrest L

Delphi Developer
Wed, 08 Sep 2004 11:45:40 GMT

Re:deadlock update conflicts with concurrent update.


Hi, Craig,

It still a deadlock if two users edit the same record. The first user
performs POST has not problem. The secord user will be deadlock. How to
prevent this? And why another user cannot see the changed after a record is
updated by a user?

Thanks & Best Regards,
Forrest

"Jeff Overcash (TeamB)" <jeffoverc...@mindspring.com>
???????:3C9BF1D6.5C431...@mindspring.com...

Quote
> CommitRetaining should have no more affect on a deadlock than Commit.  No
one
> has ever presented a test case that shows this.  The only difference
between the
> two is commit ends the transaction, but CommitRetaining leaves the
transaction
> going from the commit point.

> Forrest Lo wrote:

> > Hi, Craig,

> > So, Should I use Commit instead of CommitRetaining to prevent deadlock?

> > Thanks & Best Regards,
> > Forrest

> --
> Jeff Overcash (TeamB)
>       (Please do not email me directly unless  asked. Thank You)
> This sad little lizard told me that he was a brontosaurus on his mother's
> side.  I did not laugh; people who boast of ancestry often have little
else
> to sustain them.  Humoring them costs nothing and adds to happiness in
> a world in which happiness is in short supply.   (RAH)

Team

Delphi Developer
Wed, 08 Sep 2004 12:00:56 GMT

Re:deadlock update conflicts with concurrent update.


Quote
Forrest Lo wrote:

> Hi, Craig,

> It still a deadlock if two users edit the same record. The first user
> performs POST has not problem.

A Post is not a commit.  Until that transaction is either committed or rolled
back no one else will be able to work with the record.

Quote
> The secord user will be deadlock. How to
> prevent this? And why another user cannot see the changed after a record is
> updated by a user?

Your transaction level must be a Readcommitted level, the default for
IBTrasnaction is basically a snapshot mode.

Quote

> Thanks & Best Regards,
> Forrest

--
Jeff Overcash (TeamB)
      (Please do not email me directly unless  asked. Thank You)
This sad little lizard told me that he was a brontosaurus on his mother's
side.  I did not laugh; people who boast of ancestry often have little else
to sustain them.  Humoring them costs nothing and adds to happiness in
a world in which happiness is in short supply.   (RAH)

Other Threads

1. Deadlock Update conflicts with concurrent update

2. Deadlock Update Conflicts with Concurrent Update

3. Deadlock Update Conflicts

4. Cached Updates QUESTION: Sorting table of updated and non-updated records

5. 10 non-concurrent users, Pdox, Cached updates:

6. how to catch concurrent update errors?

7. how to update concurrent transaction ?

8. Access 97 limitations on concurrent updates?

9. 10 non-concurrent users, Pdox, Cached updates:

10. Deadlock when updating a row twice within a single DB transaction