Re: Alternative MySQL PEAR DB sequence behavior

From: Date: Sun, 22 Jul 2001 20:34:02 +0000
Subject: Re: Alternative MySQL PEAR DB sequence behavior
References: 1 2 3 4 5  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-987@lists.php.net to get a copy of this message
uksi@uksiland.com (Oleg Rekutin) wrote in news:Xns90E697DCA66F4ukstah@216.92.131.4: > Uh oh, just as I began implementing LOCK TABLES during the conversion, > I realized that we really should not it because LOCK TABLES unlocks all > previous locked tables and commits any active transactions. This will > mess up any application that attempts to retrieve the next ID during a > transaction or if it locked some other tables in the system. > > I'm thinking of ways how to eliminate race conditions and not break any > table locks or transactions. Alright, attached (hopefully the attachment goes thru, trying for the first time w/ this client) is a patch that: - fixes new IDs to start from 1 - puts a user-level lock on the conversion to prevent a race condition where two threads attempt to convert the IDs table at the same time Now, there are a few catches w/ the conversion. I avoid using LOCK TABLES, and instead use GET_LOCK, which does not commit any current transactions, nor does it abort any current table locks. It does clear any current user- level locks, but that's better than no lock at all. Possible multi-threading issues: 1) Two threads attempt to convert the table at the same time. Outcome: one of the threads will perform the conversion, then the second one will either time out waiting on the conversion to perform (unlikely) or will attempt to perform the conversion again (likely). The latter will have no effect (DELETE will affect 0 rows). 2) One thread begins conversion (pre-lock), while another thread attempts to UPDATE to get the nextId. Outcome: the 2nd thread's UPDATE will fail due to duplicates and it will attempt to perform the conversion, with the case #1 occurring. 3) One thread is after SELECT highest ID but before DELETE all but highest ID, while another thread attempts to UPDATE to get the nextId. Outcome: the 2nd thread's UPDATE will fail due to duplicates and it will attempt to perform the conversion, moving on to case #1. So I think we're in good shape... - Oleg begin 644 mysql-diff.txt M+2TM(&]L9"UM>7-Q;"YP:')4W5N($IU;"R,BQ,SHS-SHT,"R,#`Q#0HK M*RL@;7ES<6PN<&AP"5-U;B!*=6P@,C(@,38Z,C4Z,#@,CP,0T*0$`@+3,X M,RPQ,RK,S@S+#,R($!#0H@("@("@("@("@("`@("1R97-U;'0M/F=E M=$-O9&4H*2]/2!$0E]%4E)/4E].3U-50TA404),12D@>PT*("@("@("@ M("@("@("D<F5P96%T(#T@,3L-"B@("@("@("@("@("`@)')E<W5L M="]("1T:&ES+3YC<F5A=&5397%U96YC92@D<V5Q7VYA;64I.PT**R@("`@ M("@("@("@("O+R!3:6YC92!C<F5A=&5397%U96YC92!I;FET:6%L:7IE M<R!T:&4@240@=&\@8F4@,2P@#0HK("@("@("@("@("`@("\O('=E(&1O M(&YO="!N965D('1O(')E=')I979E('1H92!)1"!A9V%I;B`H;W(@=V4@=VEL M;"!G970@,BD-"B@("@("@("@("@("@:68@*$1".CII<T5R<F]R*"1R M97-U;'0I*2![#0H@("@("@("@("@("@("@("!R971U<FX@)')E<W5L M=#L-"BL@("@("@("@("@("@?2!E;'-E('L-"BL@("@("@("@("`@ M("@("@("\O($9I<G-T($E$(&]F(&$@;F5W;'D@8W)E871E9"!S97%U96YC M92!I<RQ#0HK("@("@("@("@("@("@("!R971U<FX@,3L-"B@("`@ M("@("@("@("@?0T*("@("@("@("@('T@96QS96EF("A$0CHZ:7-% M<G)O<B@D<F5S=6QT*2F)@T*("@("@("@("@("@("`D<F5S=6QT+3YG M971#;V1E*"D@/3T@1$)?15)23U)?04Q214%$65]%6$E35%,I('L-"B@("@ M("@("@("@("@+R\@375S="!B92!U<VEN9R!O;&0@<V5Q=65N8V4@96UU M;&%T:6]N(&EM<&QE;65N=&%T:6]N+T*+2@("@("@("@("@("`O+R!C M;&5A;B!U<"!T:&4@9'5P97,-"BL@("@("@("@("@("`@+R\@=V4@;F5E M9"!T;R!C;&5A;B!U<"!T:&4@9'5P97,N#0HK#0HK("@("@("@("@("`@ M("\O($]B=&%I;B!A('5S97(M;&5V96P@;&]C:RXN+B!T:&ES('=I;&P@<F5L M96%S92!A;GD@<')E=FEO=7,-"BL@("@("@("@("@("`@+R\@87!P;&EC M871I;VX@;&]C:W,L(&)U="!U;FQI:V4@3$]#2R!404),15,L(&ET(&1O97,@ M;F]T(&%B;W)T#0HK("@("@("@("@("`@("\O('1H92!C=7)R96YT('1R M86YS86-T:6]N(&%N9"!I<R!M=6-H(&QE<W,@9G)E<75E;G1L>2!U<V5D+@T* M*R@("@("@("@("@("D<F5S=6QT(#T@)'1H:7,M/F=E=$]N92@B4T5, M14-4($=%5%],3T-+*"<D>W-Q;GU?<V5Q7VQO8VLG+#$P*2(I.PT**R@("@ M("@("@("@("!I9BH1$(Z.FES17)R;W(H)')E<W5L="DI('L@#0HK("`@ M("@("@("@("@("@("!R971U<FX@)')E<W5L=#L-"BL@("@("@("@ M("@("@?0T**R@("@("@("@("@("!I9BH)')E<W5L="]/2P*2![ M#0HK("@("@("@("@("@("@("`O+R!&86EL960@=&\@9V5T('1H92!L M;V-K+"!C86XG="!D;R!T:&4@8V]N=F5R<VEO;BP@8F%I;T**R@("@("@ M("@("@("@("@+R\@=VET:"!A($1"7T524D]27TY/5%],3T-+140@97)R M;W(-"BL@("@("@("@("@("@("@(')E='5R;B`D=&AI<RT^;7ES<6Q2 M86ES945R<F]R*#$Q,#I.PT**R@("@("@("@("@("!]#0HK#0H@("`@ M("@("@("@("@("1H:6=H97-T7VED(#T@)'1H:7,M/F=E=$]N92@B4T5, M14-4($U!6"AI9"D@1E)/32D>W-Q;GU?<V5Q(BD[#0H@("@("@("@("`@ M("@(&EF("A$0CHZ:7-%<G)O<B@D:&EG:&5S=%]I9"DI('L-"B@("@("@ M("@("@("@("@(')E='5R;BD:&EG:&5S=%]I9#L-"D!("TT,#$L-B`K M-#(P+#$U($!#0H@("@("@("@("@("@(&EF("A$0CHZ:7-%<G)O<B@D M<F5S=6QT*2D@>PT*("@("@("@("@("@("@("`@<F5T=7)N("1R97-U M;'0[#0H@("@("@("@("@("@('T-"BL-"BL@("@("@("@("@("@ M+R\@268@86YO=&AE<B!T:')E860@:&%S(&)E96X@=V%I=&EN9R!F;W(@=&AI M<R!L;V-K+"-"BL@("@("@("@("@("@+R\@:70@=VEL;"!G;R!T:')U M('1H92!A8F]V92!P<F]C961U<F4L(&)U="!W:6QL(&AA=F4@;F\-"BL@("`@ M("@("@("@("@+R\@<F5A;"!E9F9E8W0-"BL@("@("@("@("@("`@ M)')E<W5L="`]("1T:&ES+3YG971/;F4H(E-%3$5#5"!214Q%05-%7TQ/0TLH M)R1[<W%N?5]S97%?;&]C:R<I(BD[#0HK("@("@("@("@("`@(&EF("A$ M0CHZ:7-%<G)O<B@D<F5S=6QT*2D@>R-"BL@("@("@("@("@("@("`@ M(')E='5R;BD<F5S=6QT.PT**R@("@("@("@("@("!]#0HK#0H@("`@ M("@("@("@("@("\O(%1H:7,@<VAO=6QD(&MI;&P@86QL(')O=W,@97AC M97!T('1H92!H:6=H97-T+"!N;W<@=V4-"B@("@("@("@("@("@+R\@ M8V%N('1R>2!A9V%I;@T*("@("@("@("@("@("D<F5P96%T(#T@,3L- M"D!("TT,C8L-RK-#4T+#<@0$-"B@("@("@(&EF("A$0CHZ:7-%<G)O M<B@D<F5S*2D@>PT*("@("@("@("@(')E='5R;BD<F5S.PT*("@("`@ M("@?0T*+2@("@("@+R\@;F5X=$ED(&-A;&P@=VEL;"!G96YE<F%T92!) M1"Q#0HK("@("@("O+R!I;G-E<G0@>6EE;&1S('9A;'5E(#$L(&YE>'1) M9"!C86QL('=I;&P@9V5N97)A=&4@240@,@T*("@("@("`@<F5T=7)N("1T M:&ES+3YQ=65R>2@B24Y315)4($E.5$\@)'MS<6Y]7W-E<2!604Q515,H,"DB /*3L-"B@("@?0T*(`T* ` end

« previous php.pear.dev (#987) next »