Subject | Re: what is the most fastest isolation level ? |
---|---|
Author | nathanelrick |
Post date | 2012-03-02T06:25:14Z |
around 100 concurrent connections, but off course all connection is to a single user and a single operation at a time
the exact error i have during my massive update is :
deadlock At trigger 'ONAFTERUPDATEUSER' line: 92, col: 5
deadlock
Error Code: 16
but as the connection is in read_commited + no_rec_version + WAIT
i can not understand why i have this deadlock :(
the exact error i have during my massive update is :
deadlock At trigger 'ONAFTERUPDATEUSER' line: 92, col: 5
deadlock
Error Code: 16
but as the connection is in read_commited + no_rec_version + WAIT
i can not understand why i have this deadlock :(
--- In firebird-support@yahoogroups.com, "Benno" <iblist@...> wrote:
>
> Hi,
>
> just curious, but how many database connections do you use in your application?
>
> If I recall correct, the client libraries (at least in Delphi) in the past were not thread safe. Don't know about current status, but perhaps that is part of your problem.
>
> Benno
>
> ----- Original Message -----
> From: nathanelrick
> To: firebird-support@yahoogroups.com
> Sent: Thursday, March 01, 2012 7:31 PM
> Subject: [firebird-support] Re: what is the most fastest isolation level ?
>
>
>
> > The problem is that the read_committed transaction will fail if it
> > tries to update a record version created by a concurrent transaction,
> > even if that transaction has committed. It's kinda dumb, but that's
> > the way it's implemented. Read-committed transactions follow the same
> > update concurrency rules as consistent read transaction. Even though a
> > read-committed transaction can read a record version that was created
> > and committed by a concurrent transaction, it can can't update that
> > version.
>
> hello ann,
>
> i just make some try (reading one of your article where you write beleave the code, not the comments) and this is my test
>
> 2 threads
>
> isc_tpb_write
> isc_tpb_read_committed
> isc_tpb_no_rec_version
> isc_tpb_wait
>
> 1rt thread Start a massive update that take 10 min to finish (update tableA set fieldA = 'xxx'); that let me the time to start thread2
>
> So i launch a second thread that do some insert/delete/update in last reccord in the tableA (that are not yet processed by the massive update)
>
> If i not commit the modification in the 2nd thread, then when the 1rt thread will arrive on the reccord updated/inserted/deleted by the 2nd thread it's will wait a commit/roolback. if in the 2nd thread i commit, then First thread will finish peacefully without any error
>
> so i no understand how it's possible to have any deadlock ?
>
>
>
>
>
> [Non-text portions of this message have been removed]
>