> 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 [email protected], "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: [email protected] >> 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 > > >
