> 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.

but because if i use isc_tpb_read_committed + isc_tpb_rec_version then for sure i will have deadlock ?

I try :

isc_tpb_read_committed
isc_tpb_rec_version
isc_tpb_wait

then

user1 start transaction
user2 start transaction
user1 Update user set xxx = 10 where id=1;
user2 Update user set xxx = 12 where id=1; => app wait
user1 commit transaction
user2 Update conflicts with concurrent update (deadlock)

so it's for sure that with rec_version i will alway have deadlock with massive update. but with isc_tpb_no_rec_version then their in no error ....

just that i don't understand why in my massive update i still have error (but it's not a Update conflicts with concurrent update, it's just a deadlock Error 16)

> *g*). What is the trigger doing. What's the DDL ...

the ddl is a little long, but to resume the trigger just update one field in 40% of row of around 20 tables

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