154 error

Hi All, I just upgrade our IDS from Ver731 to Ver115UC3 on aix V5.3tl8 few days ago on our development server. I start to process our daily transaction files. And at one point get 154 error which is lock time out expired. Not quite sure what it really means. I try to process another sets of transaction files today and produces no error. Could it related to new configuration file? I attach our original v731 configuration file and new V115 configuration file. Hope somebody could point me to right direction. Thanks, Denny ******************************************* The information contained in this e-mail message may contain privileged and confidential information. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you have received this message in error, please notify the sender by return e-mail, delete this message and destroy any copies. Internet e- mail is not guaranteed to be secure or error-free. Messages could be intercepted, corrupted, lost, arrive late or contain viruses. The sender will not be liable for these risks. ******************************************* Ce message électronique pourrait contenir des informations privilégiées et confidentielles. Si vous n'en êtes pas le récipiendaire prévu, nous vous signalons qu'il est strictement interdit d'examiner, de diffuser, de distribuer et de reproduire le présent message. Si vous l'avez reçu par erreur, veuillez prévenir l'expéditeur par courriel, puis effacer ce message et en détruire toute copie. Le courrier électronique n'est pas garanti sécuritaire ni exempt d'erreurs. Les messages pourraient être interceptés, corrompus, égarés, retardés ou contaminés par des virus. L'expéditeur n'est pas responsable de ces risques.

Attachments don' t flow through the forum interface, we don't see them. ISAM error -154, lock timeout, happens when a task that is running a serversession with SET LOCK MODE TO WAIT <n-seconds>; encounters a lock that persists for more than n seconds. It has nothing to do with the ONCONFIG settings (OK very little). Likely some other process which is badly behaved was hung or paused while holding a lock, or was engaged in a massive transaction holding many locks for a long period of time before committing. The fact that today you are not getting the error indicates that the timing of other applications is such that they are not interferring with the transaction load. Art On Tue, Jan 20, 2009 at 1:00 PM, Guo, Denny <DGuo@livingstonintl.com> wrote: > Hi All, > > I just upgrade our IDS from Ver731 to Ver115UC3 on aix V5.3tl8 few days ago > on > our development server. > I start to process our daily transaction files. And at one point get 154 > error > which is lock time out expired. > Not quite sure what it really means. I try to process another sets of > transaction files today and produces no error. > Could it related to new configuration file? I attach our original v731 > configuration file and new V115 configuration file. > Hope somebody could point me to right direction. > > Thanks, > Denny > > ******************************************* > > The information contained in this e-mail message may > contain privileged and confidential information. > If you are not the intended recipient, you are > hereby notified that any review, dissemination, > distribution or duplication of this communication > is strictly prohibited. If you have received this > message in error, please notify the sender by return > e-mail, delete this message and destroy any copies. > Internet e- mail is not guaranteed to be secure or > error-free. Messages could be intercepted, corrupted, > lost, arrive late or contain viruses. > The sender will not be liable for > these risks. > > ******************************************* > Ce message électronique pourrait contenir des informations > privilégiées et confidentielles. Si vous n'en êtes pas le > récipiendaire prévu, nous vous signalons qu'il est strictement > interdit d'examiner, de diffuser, de distribuer et de reproduire le > présent message. Si vous l'avez reçu par erreur, veuillez prévenir > l'expéditeur par courriel, puis effacer ce message et en détruire > toute copie. Le courrier électronique n'est pas garanti sécuritaire > ni exempt d'erreurs. Les messages pourraient être interceptés, > corrompus, égarés, retardés ou contaminés par des virus. > L'expéditeur n'est pas responsable de ces risques. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Oninit, the IIUG, nor any other organization with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves.

Thanks Art,=0D=0A=0D=0ABut there is only one application running=2E=0D=0ATh= e application runs update on particular transaction=2E We run the same appl= ication and process same transaction on production server, and we do not se= e the error=2E That is why upset me=2E=0D=0AThe only different is on produc= tion server using IDS731UD10 and develop server using IDS v115UC3=2E=0D=0A= =0D=0AThanks again,=0D=0ADenny=0D=0A=0D=0A-----Original Message-----=0D=0AF= rom: ids-bounces@iiug=2Eorg [mailto:ids-bounces@iiug=2Eorg] On Behalf Of Ar= t Kagel=0D=0ASent: Tuesday, January 20, 2009 3:18 PM=0D=0ATo: ids@iiug=2Eor= g=0D=0ASubject: Re: 154 error [14582]=0D=0A=0D=0A=0D=0AAttachments don' t f= low through the forum interface, we don't see them=2E=0D=0A=0D=0AISAM error= -154, lock timeout, happens when a task that is running a server=0D=0Asess= ion with SET LOCK MODE TO WAIT <n-seconds>; encounters a lock that=0D=0Aper= sists for more than n seconds=2E It has nothing to do with the ONCONFIG=0D= =0Asettings (OK very little)=2E Likely some other process which is badly be= haved=0D=0Awas hung or paused while holding a lock, or was engaged in a mas= sive=0D=0Atransaction holding many locks for a long period of time before c= ommitting=2E=0D=0AThe fact that today you are not getting the error indicat= es that the timing=0D=0Aof other applications is such that they are not int= erferring with the=0D=0Atransaction load=2E=0D=0A=0D=0AArt=0D=0A=0D=0AOn Tu= e, Jan 20, 2009 at 1:00 PM, Guo, Denny <DGuo@livingstonintl=2Ecom> wrote:= =0D=0A=0D=0A> Hi All,=0D=0A>=0D=0A> I just upgrade our IDS from Ver731 to V= er115UC3 on aix V5=2E3tl8 few days ago=0D=0A> on=0D=0A> our development ser= ver=2E=0D=0A> I start to process our daily transaction files=2E And at one = point get 154=0D=0A> error=0D=0A> which is lock time out expired=2E=0D=0A> = Not quite sure what it really means=2E I try to process another sets of=0D= =0A> transaction files today and produces no error=2E=0D=0A> Could it relat= ed to new configuration file? I attach our original v731=0D=0A> configurati= on file and new V115 configuration file=2E=0D=0A> Hope somebody could point= me to right direction=2E=0D=0A>=0D=0A> Thanks,=0D=0A> Denny=0D=0A>=0D=0A> = *******************************************=0D=0A>=0D=0A> The information c= ontained in this e-mail message may=0D=0A> contain privileged and confident= ial information=2E=0D=0A> If you are not the intended recipient, you are=0D= =0A> hereby notified that any review, dissemination,=0D=0A> distribution or= duplication of this communication=0D=0A> is strictly prohibited=2E If you = have received this=0D=0A> message in error, please notify the sender by ret= urn=0D=0A> e-mail, delete this message and destroy any copies=2E=0D=0A> Int= ernet e- mail is not guaranteed to be secure or=0D=0A> error-free=2E Messag= es could be intercepted, corrupted,=0D=0A> lost, arrive late or contain vir= uses=2E=0D=0A> The sender will not be liable for=0D=0A> these risks=2E=0D= =0A>=0D=0A> *******************************************=0D=0A> Ce message = =E9lectronique pourrait contenir des informations=0D=0A> privil=E9gi=E9es e= t confidentielles=2E Si vous n'en =EAtes pas le=0D=0A> r=E9cipiendaire pr= =E9vu, nous vous signalons qu'il est strictement=0D=0A> interdit d'examiner= , de diffuser, de distribuer et de reproduire le=0D=0A> pr=E9sent message= =2E Si vous l'avez re=E7u par erreur, veuillez pr=E9venir=0D=0A> l'exp=E9di= teur par courriel, puis effacer ce message et en d=E9truire=0D=0A> toute co= pie=2E Le courrier =E9lectronique n'est pas garanti s=E9curitaire=0D=0A> ni= exempt d'erreurs=2E Les messages pourraient =EAtre intercept=E9s,=0D=0A> c= orrompus, =E9gar=E9s, retard=E9s ou contamin=E9s par des virus=2E=0D=0A> L'= exp=E9diteur n'est pas responsable de ces risques=2E=0D=0A>=0D=0A>=0D=0A>= =0D=0A>=0D=0A**************************************************************= *****************=0D=0A> Forum Note: Use "Reply" to post a response in the = discussion forum=2E=0D=0A>=0D=0A>=0D=0A=0D=0A--=0D=0AArt S=2E Kagel=0D=0AOn= init (www=2Eoninit=2Ecom)=0D=0AIIUG Board of Directors (art@iiug=2Eorg)=0D= =0A=0D=0ADisclaimer: Please keep in mind that my own opinions are my own op= inions and=0D=0Ado not reflect on my employer, Oninit, the IIUG, nor any ot= her organization=0D=0Awith which I am associated either explicitly or impli= citly=2E Neither do=0D=0Athose opinions reflect those of other individuals = affiliated with any entity=0D=0Awith which I am affiliated nor those of the= entities themselves=2E=0D=0A=0D=0A=0D=0A**********************************= *********************************************=0D=0A Forum Note: Use "Reply= " to post a response in the discussion forum=2E=0D=0A=0D=0A****************= ***************************=0D=0A=0D=0AThe information contained in this e-= mail message may =0D=0Acontain privileged and confidential information=2E = =0D=0AIf you are not the intended recipient, you are =0D=0Ahereby notified = that any review, dissemination, =0D=0Adistribution or duplication of this c= ommunication =0D=0Ais strictly prohibited=2E If you have received this =0D= =0Amessage in error, please notify the sender by return =0D=0Ae-mail, delet= e this message and destroy any copies=2E =0D=0AInternet e- mail is not guar= anteed to be secure or =0D=0Aerror-free=2E Messages could be intercepted, c= orrupted, =0D=0Alost, arrive late or contain viruses=2E =0D=0AThe sender wi= ll not be liable for =0D=0Athese risks=2E =0D=0A=0D=0A*********************= ********************** =0D=0ACe message =E9lectronique pourrait contenir de= s informations=0Aprivil=E9gi=E9es et confidentielles=2E Si vous n'en =EAtes= pas le=0Ar=E9cipiendaire pr=E9vu, nous vous signalons qu'il est strictemen= t=0Ainterdit d'examiner, de diffuser, de distribuer et de reproduire le=0Ap= r=E9sent message=2E Si vous l'avez re=E7u par erreur, veuillez pr=E9venir= =0Al'exp=E9diteur par courriel, puis effacer ce message et en d=E9truire=0A= toute copie=2E Le courrier =E9lectronique n'est pas garanti s=E9curitaire= =0Ani exempt d'erreurs=2E Les messages pourraient =EAtre intercept=E9s,=0Ac= orrompus, =E9gar=E9s, retard=E9s ou contamin=E9s par des virus=2E=0AL'exp= =E9diteur n'est pas responsable de ces risques=2E

Whoa, big formatting problem there. Denny, There's something going on there. You simply cannot get a lock timeout if you are not contending for locks somehow. The one other possibility would be a long checkpoint blocking the application in a critical section, but checkpoints are non-blocking in 11.50, so that also should not happen. Does the one application maintain multiple connections to the server? Is there a SELECT ... FOR UPDATE loop with insert, delete, or updates happening inside the loop? Art On Tue, Jan 20, 2009 at 3:28 PM, Guo, Denny <DGuo@livingstonintl.com> wrote: > Thanks Art,=0D=0A=0D=0ABut there is only one application > running=2E=0D=0ATh= > e application runs update on particular transaction=2E We run the same > appl= > ication and process same transaction on production server, and we do not > se= > e the error=2E That is why upset me=2E=0D=0AThe only different is on > produc= > tion server using IDS731UD10 and develop server using IDS v115UC3=2E=0D=0A= > =0D=0AThanks again,=0D=0ADenny=0D=0A=0D=0A-----Original > Message-----=0D=0AF= > rom: ids-bounces@iiug=2Eorg [mailto:ids-bounces@iiug=2Eorg] On Behalf Of > Ar= > t Kagel=0D=0ASent: Tuesday, January 20, 2009 3:18 PM=0D=0ATo: ids@iiug > =2Eor= > g=0D=0ASubject: Re: 154 error [14582]=0D=0A=0D=0A=0D=0AAttachments don' t > f= > low through the forum interface, we don't see them=2E=0D=0A=0D=0AISAM > error= > -154, lock timeout, happens when a task that is running a server=0D=0Asess= > ion with SET LOCK MODE TO WAIT <n-seconds>; encounters a lock > that=0D=0Aper= > sists for more than n seconds=2E It has nothing to do with the ONCONFIG=0D= > =0Asettings (OK very little)=2E Likely some other process which is badly > be= > haved=0D=0Awas hung or paused while holding a lock, or was engaged in a > mas= > sive=0D=0Atransaction holding many locks for a long period of time before > c= > ommitting=2E=0D=0AThe fact that today you are not getting the error > indicat= > es that the timing=0D=0Aof other applications is such that they are not > int= > erferring with the=0D=0Atransaction load=2E=0D=0A=0D=0AArt=0D=0A=0D=0AOn > Tu= > e, Jan 20, 2009 at 1:00 PM, Guo, Denny <DGuo@livingstonintl=2Ecom> wrote:= > =0D=0A=0D=0A> Hi All,=0D=0A>=0D=0A> I just upgrade our IDS from Ver731 to > V= > er115UC3 on aix V5=2E3tl8 few days ago=0D=0A> on=0D=0A> our development > ser= > ver=2E=0D=0A> I start to process our daily transaction files=2E And at one > = > point get 154=0D=0A> error=0D=0A> which is lock time out expired=2E=0D=0A> > = > Not quite sure what it really means=2E I try to process another sets of=0D= > =0A> transaction files today and produces no error=2E=0D=0A> Could it > relat= > ed to new configuration file? I attach our original v731=0D=0A> > configurati= > on file and new V115 configuration file=2E=0D=0A> Hope somebody could > point= > me to right direction=2E=0D=0A>=0D=0A> Thanks,=0D=0A> Denny=0D=0A>=0D=0A> = > *******************************************=0D=0A>=0D=0A> The information > c= > ontained in this e-mail message may=0D=0A> contain privileged and > confident= > ial information=2E=0D=0A> If you are not the intended recipient, you > are=0D= > =0A> hereby notified that any review, dissemination,=0D=0A> distribution > or= > duplication of this communication=0D=0A> is strictly prohibited=2E If you = > have received this=0D=0A> message in error, please notify the sender by > ret= > urn=0D=0A> e-mail, delete this message and destroy any copies=2E=0D=0A> > Int= > ernet e- mail is not guaranteed to be secure or=0D=0A> error-free=2E > Messag= > es could be intercepted, corrupted,=0D=0A> lost, arrive late or contain > vir= > uses=2E=0D=0A> The sender will not be liable for=0D=0A> these risks=2E=0D= > =0A>=0D=0A> *******************************************=0D=0A> Ce message = > =E9lectronique pourrait contenir des informations=0D=0A> privil=E9gi=E9es > e= > t confidentielles=2E Si vous n'en =EAtes pas le=0D=0A> r=E9cipiendaire pr= > =E9vu, nous vous signalons qu'il est strictement=0D=0A> interdit > d'examiner= > , de diffuser, de distribuer et de reproduire le=0D=0A> pr=E9sent message= > =2E Si vous l'avez re=E7u par erreur, veuillez pr=E9venir=0D=0A> > l'exp=E9di= > teur par courriel, puis effacer ce message et en d=E9truire=0D=0A> toute > co= > pie=2E Le courrier =E9lectronique n'est pas garanti s=E9curitaire=0D=0A> > ni= > exempt d'erreurs=2E Les messages pourraient =EAtre intercept=E9s,=0D=0A> c= > orrompus, =E9gar=E9s, retard=E9s ou contamin=E9s par des virus=2E=0D=0A> > L'= > exp=E9diteur n'est pas responsable de ces risques=2E=0D=0A>=0D=0A>=0D=0A>= > > =0D=0A>=0D=0A**************************************************************= > *****************=0D=0A> Forum Note: Use "Reply" to post a response in the > = > discussion forum=2E=0D=0A>=0D=0A>=0D=0A=0D=0A--=0D=0AArt S=2E > Kagel=0D=0AOn= > init (www=2Eoninit=2Ecom)=0D=0AIIUG Board of Directors (art@iiug > =2Eorg)=0D= > =0A=0D=0ADisclaimer: Please keep in mind that my own opinions are my own > op= > inions and=0D=0Ado not reflect on my employer, Oninit, the IIUG, nor any > ot= > her organization=0D=0Awith which I am associated either explicitly or > impli= > citly=2E Neither do=0D=0Athose opinions reflect those of other individuals > = > affiliated with any entity=0D=0Awith which I am affiliated nor those of > the= > entities themselves=2E=0D=0A=0D=0A=0D=0A**********************************= > *********************************************=0D=0A Forum Note: Use "Reply= > " to post a response in the discussion > forum=2E=0D=0A=0D=0A****************= > ***************************=0D=0A=0D=0AThe information contained in this > e-= > mail message may =0D=0Acontain privileged and confidential information=2E = > =0D=0AIf you are not the intended recipient, you are =0D=0Ahereby notified > = > that any review, dissemination, =0D=0Adistribution or duplication of this > c= > ommunication =0D=0Ais strictly prohibited=2E If you have received this =0D= > =0Amessage in error, please notify the sender by return =0D=0Ae-mail, > delet= > e this message and destroy any copies=2E =0D=0AInternet e- mail is not > guar= > anteed to be secure or =0D=0Aerror-free=2E Messages could be intercepted, > c= > orrupted, =0D=0Alost, arrive late or contain viruses=2E =0D=0AThe sender > wi= > ll not be liable for =0D=0Athese risks=2E > =0D=0A=0D=0A*********************= > ********************** =0D=0ACe message =E9lectronique pourrait contenir > de= > s informations=0Aprivil=E9gi=E9es et confidentielles=2E Si vous n'en > =EAtes= > pas le=0Ar=E9cipiendaire pr=E9vu, nous vous signalons qu'il est strictemen= > t=0Ainterdit d'examiner, de diffuser, de distribuer et de reproduire > le=0Ap= > r=E9sent message=2E Si vous l'avez re=E7u par erreur, veuillez pr=E9venir= > =0Al'exp=E9diteur par courriel, puis effacer ce message et en > d=E9truire=0A= > toute copie=2E Le courrier =E9lectronique n'est pas garanti s=E9curitaire= > =0Ani exempt d'erreurs=2E Les messages pourraient =EAtre > intercept=E9s,=0Ac= > orrompus, =E9gar=E9s, retard=E9s ou contamin=E9s par des virus=2E=0AL'exp= > =E9diteur n'est pas responsable

Thanks for quick reply, Art=2E=0D=0A=0D=0AI guest I found out why=2E It is = just bad timing=2E=0D=0AOur application is using repeatable-read isolation = mode=2E=0D=0AOur db design is like this=2E Table B is child table of table = A=2E=0D=0AI finally found that when we try to update table A and there is a= nother session try to update table B and will require information from tabl= e A=2E=0D=0AThat is why causing failure=2E On production server, the proces= sing timing is not causing problem=2E=0D=0A=0D=0APlease correct me if my un= derstanding is wrong=2E=0D=0A=0D=0AThanks,=0D=0ADenny=0D=0A=0D=0A=0D=0A----= -Original Message-----=0D=0AFrom: ids-bounces@iiug=2Eorg [mailto:ids-bounce= s@iiug=2Eorg] On Behalf Of Art Kagel=0D=0ASent: Tuesday, January 20, 2009 3= :45 PM=0D=0ATo: ids@iiug=2Eorg=0D=0ASubject: Re: 154 error [14584]=0D=0A=0D= =0A=0D=0AWhoa, big formatting problem there=2E Denny, There's something goi= ng on=0D=0Athere=2E You simply cannot get a lock timeout if you are not con= tending for=0D=0Alocks somehow=2E The one other possibility would be a long= checkpoint=0D=0Ablocking the application in a critical section, but checkp= oints are=0D=0Anon-blocking in 11=2E50, so that also should not happen=2E D= oes the one=0D=0Aapplication maintain multiple connections to the server? I= s there a SELECT=0D=0A=2E=2E=2E=2E=2E FOR UPDATE loop with insert, delete, = or updates happening inside the=0D=0Aloop?=0D=0A=0D=0AA8rt=0D=0A=0D=0AOn Tu= e, Jan 20, 2009 at 3:28 PM, Guo, Denny <DGuo@livingstonintl=2Ecom> wrote:= =0D=0A=0D=0A> Thanks Art,=3D0D=3D0A=3D0D=3D0ABut there is only one applicat= ion=0D=0A> running=3D2E=3D0D=3D0ATh=3D=0D=0A> e application runs update on = particular transaction=3D2E We run the same=0D=0A> appl=3D=0D=0A> ication a= nd process same transaction on production server, and we do not=0D=0A> se= =3D=0D=0A> e the error=3D2E That is why upset me=3D2E=3D0D=3D0AThe only dif= ferent is on=0D=0A> produc=3D=0D=0A> tion server using IDS731UD10 and devel= op server using IDS v115UC3=3D2E=3D0D=3D0A=3D=0D=0A> =3D0D=3D0AThanks again= ,=3D0D=3D0ADenny=3D0D=3D0A=3D0D=3D0A-----Original=0D=0A> Message-----=3D0D= =3D0AF=3D=0D=0A> rom: ids-bounces@iiug=3D2Eorg [mailto:ids-bounces@iiug=3D2= Eorg] On Behalf Of=0D=0A> Ar=3D=0D=0A> t Kagel=3D0D=3D0ASent: Tuesday, Janu= ary 20, 2009 3:18 PM=3D0D=3D0ATo: ids@iiug=0D=0A> =3D2Eor=3D=0D=0A> g=3D0D= =3D0ASubject: Re: 154 error [14582]=3D0D=3D0A=3D0D=3D0A=3D0D=3D0AAttachment= s don' t=0D=0A> f=3D=0D=0A> low through the forum interface, we don't see t= hem=3D2E=3D0D=3D0A=3D0D=3D0AISAM=0D=0A> error=3D=0D=0A> -154, lock timeout,= happens when a task that is running a server=3D0D=3D0Asess=3D=0D=0A> ion w= ith SET LOCK MODE TO WAIT <n-seconds>; encounters a lock=0D=0A> that=3D0D= =3D0Aper=3D=0D=0A> sists for more than n seconds=3D2E It has nothing to do = with the ONCONFIG=3D0D=3D=0D=0A> =3D0Asettings (OK very little)=3D2E Likely= some other process which is badly=0D=0A> be=3D=0D=0A> haved=3D0D=3D0Awas h= ung or paused while holding a lock, or was engaged in a=0D=0A> mas=3D=0D=0A= > sive=3D0D=3D0Atransaction holding many locks for a long period of time be= fore=0D=0A> c=3D=0D=0A> ommitting=3D2E=3D0D=3D0AThe fact that today you are= not getting the error=0D=0A> indicat=3D=0D=0A> es that the timing=3D0D=3D0= Aof other applications is such that they are not=0D=0A> int=3D=0D=0A> erfer= ring with the=3D0D=3D0Atransaction load=3D2E=3D0D=3D0A=3D0D=3D0AArt=3D0D=3D= 0A=3D0D=3D0AOn=0D=0A> Tu=3D=0D=0A> e, Jan 20, 2009 at 1:00 PM, Guo, Denny <= DGuo@livingstonintl=3D2Ecom> wrote:=3D=0D=0A> =3D0D=3D0A=3D0D=3D0A> Hi All,= =3D0D=3D0A>=3D0D=3D0A> I just upgrade our IDS from Ver731 to=0D=0A> V=3D=0D= =0A> er115UC3 on aix V5=3D2E3tl8 few days ago=3D0D=3D0A> on=3D0D=3D0A> our = development=0D=0A> ser=3D=0D=0A> ver=3D2E=3D0D=3D0A> I start to process our= daily transaction files=3D2E And at one=0D=0A> =3D=0D=0A> point get 154=3D= 0D=3D0A> error=3D0D=3D0A> which is lock time out expired=3D2E=3D0D=3D0A>=0D= =0A> =3D=0D=0A> Not quite sure what it really means=3D2E I try to process a= nother sets of=3D0D=3D=0D=0A> =3D0A> transaction files today and produces n= o error=3D2E=3D0D=3D0A> Could it=0D=0A> relat=3D=0D=0A> ed to new configura= tion file? I attach our original v731=3D0D=3D0A>=0D=0A> configurati=3D=0D= =0A> on file and new V115 configuration file=3D2E=3D0D=3D0A> Hope somebody = could=0D=0A> point=3D=0D=0A> me to right direction=3D2E=3D0D=3D0A>=3D0D=3D0= A> Thanks,=3D0D=3D0A> Denny=3D0D=3D0A>=3D0D=3D0A> =3D=0D=0A> **************= *****************************=3D0D=3D0A>=3D0D=3D0A> The information=0D=0A> = c=3D=0D=0A> ontained in this e-mail message may=3D0D=3D0A> contain privileg= ed and=0D=0A> confident=3D=0D=0A2> ial information=3D2E=3D0D=3D0A> If you a= re not the intended recipient, you=0D=0A> are=3D0D=3D=0D=0A> =3D0A> hereby = notified that any review, dissemination,=3D0D=3D0A> distribution=0D=0A> or= =3D=0D=0A> duplication of this communication=3D0D=3D0A> is strictly prohibi= ted=3D2E If you =3D=0D=0A> have received this=3D0D=3D0A> message in error, = please notify the sender by=0D=0A> ret=3D=0D=0A> urn=3D0D=3D0A> e-mail, del= ete this message and destroy any copies=3D2E=3D0D=3D0A>=0D=0A> Int=3D=0D=0A= > ernet e- mail is not guaranteed to be secure or=3D0D=3D0A> error-free=3D2= E=0D=0A> Messag=3D=0D=0A> es could be intercepted, corrupted,=3D0D=3D0A> lo= st, arrive late or contain=0D=0A> vir=3D=0D=0A> uses=3D2E=3D0D=3D0A> The se= nder will not be liable for=3D0D=3D0A> these risks=3D2E=3D0D=3D=0D=0A> =3D0= A>=3D0D=3D0A> *******************************************=3D0D=3D0A> Ce mes= sage =3D=0D=0A> =3DE9lectronique pourrait contenir des informations=3D0D=3D= 0A> privil=3DE9gi=3DE9es=0D=0A> e=3D=0D=0A> t confidentielles=3D2E Si vous = n'en =3DEAtes pas le=3D0D=3D0A> r=3DE9cipiendaire pr=3D=0D=0A> =3DE9vu, nou= s vous signalons qu'il est strictement=3D0D=3D0A> interdit=0D=0A> d'examine= r=3D=0D=0A> , de diffuser, de distribuer et de reproduire le=3D0D=3D0A> pr= =3DE9sent message=3D=0D=0A> =3D2E Si vous l'avez re=3DE7u par erreur, veuil= lez pr=3DE9venir=3D0D=3D0A>=0D=0A> l'exp=3DE9di=3D=0D=0A> teur par courriel= , puis effacer ce message et en d=3DE9truire=3D0D=3D0A> toute=0D=0A> co=3D= =0D=0A> pie=3D2E Le courrier =3DE9lectronique n'est pas garanti s=3DE9curit= aire=3D0D=3D0A>=0D=0A> ni=3D=0D=0A> exempt d'erreurs=3D2E Les messages pour= raient =3DEAtre intercept=3DE9s,=3D0D=3D0A> c=3D=0D=0A> orrompus, =3DE9gar= =3DE9s, retard=3DE9s ou contamin=3DE9s par des virus=3D2E=3D0D=3D0A>=0D=0A>= L'=3D=0D=0A> exp=3DE9diteur n'est pas responsable de ces risques=3D2E=3D0D= =3D0A>=3D0D=3D0A>=3D0D=3D0A>=3D=0D=0A>=0D=0A> =3D0D=3D0A>=3D0D=3D0A********= ******************************************************=3D=0D=0A> **********= *******=3D0D=3D0A> Forum Note: Use "Reply" to post a response in the=0D=0A>= =3D=0D=0A> discussion forum=3D2E=3D0D=3D0A>=3D0D=3D0A>=3D0D=3D0A=3D0D=3D0A= --=3D0D=3D0AArt S=3D2E=0D=0A> Kagel=3D0D=3D0AOn=3D=0D=0A> init (www=3D2Eoni= nit=3D2Ecom)=3D0D=3D0AIIUG Board of Directors (art@iiug=0D=0A> =3D2Eorg)=3D= 0D=3D=0D=0A> =3D0A=3D0D=3D0ADisclaimer: Please keep in mind that my own opi= nions are my own=0D=0A> op=3D=0D=0A> inions and=3D0D=3D0Ado not reflect on = my employer, Oninit, the IIUG, nor any=0D=0A> ot=3D=0D=0A> her organization= =3D0D=3D0Awith which I am associated either explicitly or=0D=0A> impli=3D= =0D=0A> citly=3D2E Neither do=3D0D=3D0Ath

Yuck, you have to adjust your email client, it's mangling your posts. Anyway, your description jives with what I would expect yes. Art On Tue, Jan 20, 2009 at 3:56 PM, Guo, Denny <DGuo@livingstonintl.com> wrote: > Thanks for quick reply, Art. I guest I found out why. It is just bad > timing. > Our application is using repeatable-read isolation mode. > Our db design is like this: Table B is child table of table A > I finally found that when we try to update table A and there is another > session try to update table B and will require information from table A. > That is why causing failure=2E On production server, the processing timing > is not causing problem. > Please correct me if my understanding is wrong. > =2E=0D=0A=0D=0AThanks,=0D=0ADenny=0D=0A=0D=0A=0D=0A----= > -Original Message-----=0D=0AFrom: ids-bounces@iiug=2Eorg [mailto: > ids-bounce= > s@iiug=2Eorg] On Behalf Of Art Kagel=0D=0ASent: Tuesday, January 20, 2009 > 3= > :45 PM=0D=0ATo: ids@iiug=2Eorg=0D=0ASubject: Re: 154 error > [14584]=0D=0A=0D= > =0A=0D=0AWhoa, big formatting problem there=2E Denny, There's something > goi= > ng on=0D=0Athere=2E You simply cannot get a lock timeout if you are not > con= > tending for=0D=0Alocks somehow=2E The one other possibility would be a > long= > checkpoint=0D=0Ablocking the application in a critical section, but checkp= > oints are=0D=0Anon-blocking in 11=2E50, so that also should not happen=2E > D= > oes the one=0D=0Aapplication maintain multiple connections to the server? > I= > s there a SELECT=0D=0A=2E=2E=2E=2E=2E FOR UPDATE loop with insert, delete, > = > or updates happening inside the=0D=0Aloop?=0D=0A=0D=0AA8rt=0D=0A=0D=0AOn > Tu= > e, Jan 20, 2009 at 3:28 PM, Guo, Denny <DGuo@livingstonintl=2Ecom> wrote:= > =0D=0A=0D=0A> Thanks Art,=3D0D=3D0A=3D0D=3D0ABut there is only one > applicat= > ion=0D=0A> running=3D2E=3D0D=3D0ATh=3D=0D=0A> e application runs update on > = > particular transaction=3D2E We run the same=0D=0A> appl=3D=0D=0A> ication > a= > nd process same transaction on production server, and we do not=0D=0A> se= > =3D=0D=0A> e the error=3D2E That is why upset me=3D2E=3D0D=3D0AThe only > dif= > ferent is on=0D=0A> produc=3D=0D=0A> tion server using IDS731UD10 and > devel= > op server using IDS v115UC3=3D2E=3D0D=3D0A=3D=0D=0A> =3D0D=3D0AThanks > again= > ,=3D0D=3D0ADenny=3D0D=3D0A=3D0D=3D0A-----Original=0D=0A> Message-----=3D0D= > =3D0AF=3D=0D=0A> rom: ids-bounces@iiug=3D2Eorg [mailto:ids-bounces@iiug > =3D2= > Eorg] On Behalf Of=0D=0A> Ar=3D=0D=0A> t Kagel=3D0D=3D0ASent: Tuesday, > Janu= > ary 20, 2009 3:18 PM=3D0D=3D0ATo: ids@iiug=0D=0A> =3D2Eor=3D=0D=0A> > g=3D0D= > =3D0ASubject: Re: 154 error > [14582]=3D0D=3D0A=3D0D=3D0A=3D0D=3D0AAttachment= > s don' t=0D=0A> f=3D=0D=0A> low through the forum interface, we don't see > t= > hem=3D2E=3D0D=3D0A=3D0D=3D0AISAM=0D=0A> error=3D=0D=0A> -154, lock > timeout,= > happens when a task that is running a server=3D0D=3D0Asess=3D=0D=0A> ion w= > ith SET LOCK MODE TO WAIT <n-seconds>; encounters a lock=0D=0A> that=3D0D= > =3D0Aper=3D=0D=0A> sists for more than n seconds=3D2E It has nothing to do > = > with the ONCONFIG=3D0D=3D=0D=0A> =3D0Asettings (OK very little)=3D2E > Likely= > some other process which is badly=0D=0A> be=3D=0D=0A> haved=3D0D=3D0Awas h= > ung or paused while holding a lock, or was engaged in a=0D=0A> > mas=3D=0D=0A= > > sive=3D0D=3D0Atransaction holding many locks for a long period of time > be= > fore=0D=0A> c=3D=0D=0A> ommitting=3D2E=3D0D=3D0AThe fact that today you > are= > not getting the error=0D=0A> indicat=3D=0D=0A> es that the timing=3D0D=3D0= > Aof other applications is such that they are not=0D=0A> int=3D=0D=0A> > erfer= > ring with the=3D0D=3D0Atransaction > load=3D2E=3D0D=3D0A=3D0D=3D0AArt=3D0D=3D= > 0A=3D0D=3D0AOn=0D=0A> Tu=3D=0D=0A> e, Jan 20, 2009 at 1:00 PM, Guo, Denny > <= > DGuo@livingstonintl=3D2Ecom> wrote:=3D=0D=0A> =3D0D=3D0A=3D0D=3D0A> Hi > All,= > =3D0D=3D0A>=3D0D=3D0A> I just upgrade our IDS from Ver731 to=0D=0A> > V=3D=0D= > =0A> er115UC3 on aix V5=3D2E3tl8 few days ago=3D0D=3D0A> on=3D0D=3D0A> our > = > development=0D=0A> ser=3D=0D=0A> ver=3D2E=3D0D=3D0A> I start to process > our= > daily transaction files=3D2E And at one=0D=0A> =3D=0D=0A> point get 154=3D= > 0D=3D0A> error=3D0D=3D0A> which is lock time out > expired=3D2E=3D0D=3D0A>=0D= > =0A> =3D=0D=0A> Not quite sure what it really means=3D2E I try to process > a= > nother sets of=3D0D=3D=0D=0A> =3D0A> transaction files today and produces > n= > o error=3D2E=3D0D=3D0A> Could it=0D=0A> relat=3D=0D=0A> ed to new > configura= > tion file? I attach our original v731=3D0D=3D0A>=0D=0A> configurati=3D=0D= > =0A> on file and new V115 configuration file=3D2E=3D0D=3D0A> Hope somebody > = > could=0D=0A> point=3D=0D=0A> me to right > direction=3D2E=3D0D=3D0A>=3D0D=3D0= > A> Thanks,=3D0D=3D0A> Denny=3D0D=3D0A>=3D0D=3D0A> =3D=0D=0A> > **************= > *****************************=3D0D=3D0A>=3D0D=3D0A> The information=0D=0A> > = > c=3D=0D=0A> ontained in this e-mail message may=3D0D=3D0A> contain > privileg= > ed and=0D=0A> confident=3D=0D=0A2> ial information=3D2E=3D0D=3D0A> If you > a= > re not the intended recipient, you=0D=0A> are=3D0D=3D=0D=0A> =3D0A> hereby > = > notified that any review, dissemination,=3D0D=3D0A> distribution=0D=0A> or= > =3D=0D=0A> duplication of this communication=3D0D=3D0A> is strictly > prohibi= > ted=3D2E If you =3D=0D=0A> have received this=3D0D=3D0A> message in error, > = > please notify the sender by=0D=0A> ret=3D=0D=0A> urn=3D0D=3D0A> e-mail, > del= > ete this message and destroy any copies=3D2E=3D0D=3D0A>=0D=0A> > Int=3D=0D=0A= > > ernet e- mail is not guaranteed to be secure or=3D0D=3D0A> > error-free=3D2= > E=0D=0A> Messag=3D=0D=0A> es could be intercepted, corrupted,=3D0D=3D0A> > lo= > st, arrive late or contain=0D=0A> vir=3D=0D=0A> uses=3D2E=3D0D=3D0A> The > se= > nder will not be liable for=3D0D=3D0A> these risks=3D2E=3D0D=3D=0D=0A> > =3D0= > A>=3D0D=3D0A> *******************************************=3D0D=3D0A> Ce > mes= > sage =3D=0D=0A> =3DE9lectronique pourrait contenir des > informations=3D0D=3D= > 0A> privil=3DE9gi=3DE9es=0D=0A> e=3D=0D=0A> t confidentielles=3D2E Si vous > = > n'en =3DEAtes pas le=3D0D=3D0A> r=3DE9cipiendaire pr=3D=0D=0A> =3DE9vu, > nou= > s vous signalons qu'il est strictement=3D0D=3D0A> interdit=0D=0A> > d'examine= > r=3D=0D=0A> , de diffuser, de distribuer et de reproduire le=3D0D=3D0A> pr= > =3DE9sent message=3D=0D=0A> =3D2E Si vous l'avez re=3DE7u par erreur, > veuil= > lez pr=3DE9venir=3D0D=3D0A>=0D=0A> l'exp=3DE9di=3D=0D=0A> teur par > courriel= > , puis effacer ce message et en d=3DE9truire=3D0D=3D0A> toute=0D=0A> co=3D= > =0D=0A> pie=3D2E Le courrier =3DE9lectronique n'est pas garanti > s=3DE9curit= > aire=3D0D=3D0A>=0D=0A> ni=3D=0D=0A> exempt d'erreurs=3D2E Les messages > pour= > raient =3DEAtre intercept=3DE9s,=3D0D=3D0A> c=3D=0D=0A> orrompus, =3DE9gar= > =3DE9s, retard=3DE9s ou contamin=3DE9s par des > virus=3D2E=3D0D=3D0A>=0D=0A>= > L'=3D=0D=0A> exp=3DE9diteur n'est pas responsable de ces risques=3D2E=3D0D= > =3D0A>=3D0D=3D0A>=3D0D