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