Grouping Statements Using Locks

• Your server m ay not support t ransact ions at all. I t m ay be t oo old or not configured wit h t he appropriat e t able handlers, as discussed in Recipe 15.2 . I n t his case, you have no choice but t o use som e kind of workaround for t ransact ions. One st rat egy t hat can be helpful in som e sit uat ions is t o use explicit t able locking t o prevent concurrency problem s. • Applicat ions som et im es use t ransact ions when t heyre not really necessary. You m ay be able t o elim inat e t he need for a t ransact ion by rewrit ing st at em ent s. This m ay even result in a fast er applicat ion.

15.9.4 Grouping Statements Using Locks

I f your server doesnt have t ransact ional capabilit ies but you need t o execut e a group of queries wit hout int erference by ot her client s, you can do so by using LOCK TABLE and UNLOCK TABLE : [1] [1] LOCK TABLES and UNLOCK TABLES are synonyms for LOCK TABLE and UNLOCK TABLE . • Use LOCK TABLE t o obt ain locks for all t he t ables you int end t o use. Acquire writ e locks for t ables you need t o m odify, and read locks for t he ot hers. This prevent s ot her client s from m odifying t he t ables while youre using t hem . • I ssue t he queries t hat m ust be execut ed as a group. • Release t he locks wit h UNLOCK TABLE . Ot her client s will regain access t o t he t ables. Locks obt ained wit h LOCK TABLE rem ain in effect unt il you release t hem and t hus can apply over t he course of m ult iple st at em ent s. This gives you t he sam e concurrency benefit s as t ransact ions. However, t here is no rollback if errors occur, so t able locking is not appropriat e for all applicat ions. For exam ple, you m ight t ry perform ing an operat ion t hat t ransfers funds from Eve t o I da like t his: LOCK TABLE money WRITE; UPDATE money SET amt = amt - 6 WHERE name = Eve; UPDATE money SET amt = amt + 6 WHERE name = Ida; UNLOCK TABLE; Unfort unat ely, if t he second updat e fails, t he effect of t he first updat e is not rolled back. Despit e t his caveat , t here are cert ain t ypes of sit uat ions where t able locking m ay be sufficient for your purposes: • A set of st at em ent s consist ing only of SELECT queries. I f you want t o run several SELECT st at em ent s and prevent ot her client s from m odifying t he t ables while youre querying t hem , locking will do t hat . For exam ple, if you need t o run several sum m ary queries on a set of t ables, your sum m aries m ay appear t o be based on different set s of dat a if ot her client s are allowed t o change records in bet ween your sum m ary queries. This will m ake t he sum m aries inconsist ent . To prevent t hat from happening, lock t he t ables while youre using t hem . • Locking also can be useful for a set of queries where only t he last st at em ent is an updat e. I n t his case, t he earlier st at em ent s dont m ake any changes and t here is not hing t hat needs t o be rolled back should t he updat e fail.

15.9.5 Rewriting Queries to Avoid Transactions