> 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 :(

It's not the connection, it's the transaction which is in the above
mentioned mode. I don't understand why you resist on using no_rec_version.

You didn't mention the above trigger so far (at least I can't remember
*g*). What is the trigger doing. What's the DDL ...


--
With regards,
Thomas Steinmaurer (^TS^)
Firebird Technology Evangelist

http://www.upscene.com/

Do you care about the future of Firebird? Join the Firebird Foundation:
http://www.firebirdsql.org/en/firebird-foundation/

> --- 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]
>>
>
>
>
>
> ------------------------------------
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Visit http://www.firebirdsql.org and click the Resources item
> on the main (top) menu. Try Knowledgebase and FAQ links !
>
> Also search the knowledgebases at http://www.ibphoenix.com
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Yahoo! Groups Links
>
>
>