Knowledge

Record locking

Source đź“ť

249:(locking one entity, then locking one or more additional entities) is used. To illustrate, if two bank customers asked two clerks to obtain their account information so they could transfer some money into other accounts, the two accounts would essentially be locked. Then, if the customers told their clerks that the money was to be transferred into each other's accounts, the clerks would search for the other accounts but find them to be "in use" and wait for them to be returned. Unknowingly, the two clerks are waiting for each other, and neither of them can complete their transaction until the other gives up and returns the account. Various techniques are used to avoid such problems. 36: 154:. Clerk 1 applies and saves a transaction. Clerk 2 applies a different transaction to his saved copy, and saves the result, based on the original record and his changes, overwriting the transaction entered by clerk 1. The record no longer reflects the first transaction, as if it had never taken place. 319:
If lock requests for the same entity are queued, then once a shared lock is granted, any queued shared locks may also be granted. If an exclusive lock is found next on the queue, it must wait until all shared locks have been released. As with exclusive locks, these shared locks should be held for the
302:
queue. This would ensure that any possible waiter would get equal chance to obtain the lock and not be locked out. To further speed up the process, if an entity has gone to sleep waiting for a lock, performance is improved if the entity is notified of the grant, instead of discovering it on some sort
169:
when retrieved for editing or updating. Anyone attempting to retrieve the same record for editing is denied write access because of the lock (although, depending on the implementation, they may be able to view the record without editing it). Once the record is saved or edits are canceled, the lock
315:
can contain multiple entries. Shared locks allow all holders to read the contents of the record knowing that the record cannot be changed until after the lock has been released by all holders. Exclusive locks cannot be obtained when a record is already locked (exclusively or shared) by another
161:
whenever a record is being modified by any user, so that no other user can save data. This prevents records from being overwritten incorrectly, but allows only one record to be processed at a time, locking out other users who need to edit records at the same time.
264:
The application or system should be designed such that any lock is held for the shortest time possible. Data reading, without editing facilities, does not require a lock, and reading locked records is usually permissible.
226:
is achieved if each individual account may be taken by a clerk. This would allow any customer to be serviced without waiting for another customer who is accessing a different account. This is analogous to a
215:, provided that each customer's account is found on a different page than the others. If two customers have accounts on the same page, then only one may be serviced at a time. This is analogous to a 211:
If the clerks can remove one page from the ledger, containing the account of the current customer (plus several other accounts), then multiple customers can be serviced
200:
If the bank clerks (to follow the illustration above) are serving two customers, but their accounts are contained in one ledger, then the entire ledger, or one or more
276:
Exclusive locks are exclusively held by a single entity, usually for the purpose of writing to the record. If the locking schema was represented by a list, the
261:, and no other entity is effectively locked out. The entities that request a lock can be either individual applications (programs) or an entire processor. 165:
To allow several users to edit a database table at the same time and also prevent inconsistencies created by unrestricted access, a single record can be
280:
would contain only one entry. Since this type of lock effectively blocks any other entity that requires the lock from processing, care must be used to:
257:
Record locks need to be managed between the entities requesting the records such that no entity is given too much service via successive
287:
not hold the lock across system or function calls where the entity is no longer running on the processor – this can lead to deadlock;
100: 72: 204:, would need to be made available for editing to the clerks in order for each to complete a transaction, one at a time ( 79: 364: 119: 299: 390: 53: 17: 86: 212: 57: 189: 385: 68: 242: 329: 46: 356: 350: 93: 241:
The introduction of granular (subset) locks creates the possibility for a situation called
231:
and is normally the highest degree of locking granularity in a database management system.
8: 150:
for two different transactions. Clerks 1 and 2 both retrieve (i.e., copy) the account's
360: 170:
is released. Records can never be saved so as to overwrite other changes, preserving
151: 290:
ensure that if the entity is unexpectedly exited for any reason, the lock is freed.
223: 201: 171: 379: 298:) can be held in a list that is serviced in a round-robin fashion, or in a 205: 158: 147: 35: 188:
A thorough and authoritative description of locking was written by
136: 143: 135:
is the technique of preventing simultaneous access to data in a
181:
among multiple database users. This is the "I" in the acronym
177:
In database management theory, locking is used to implement
352:
Distributed Transaction Processing: Concepts and Techniques
182: 208:). While safe, this method can cause unnecessary waiting. 235: 348: 284:
ensure the lock is held for the shortest time possible;
311:
Shared locks differ from exclusive locks in that the
60:. Unsourced material may be challenged and removed. 377: 238:database, a record is typically called a "row". 142:The classic example is demonstrated by two 268:Two main types of locks can be requested: 120:Learn how and when to remove this message 349:Gray, Jim & Reuter, Andreas (1993), 195: 27:Solution for concurrent database access 14: 378: 146:clerks attempting to update the same 58:adding citations to reliable sources 29: 157:A simple way to prevent this is to 139:, to prevent inconsistent results. 24: 303:of system timeout driven wake-up. 271: 25: 402: 294:Non-holders of the lock (a.k.a. 34: 306: 252: 45:needs additional citations for 342: 13: 1: 335: 355:, Morgan Kaufmann, pp.  245:. Deadlock is possible when 7: 323: 10: 407: 391:Transaction processing 320:least time possible. 196:Granularity of locks 54:improve this article 386:Concurrency control 330:Readers–writer lock 247:incremental locking 222:A higher degree of 229:record level lock 130: 129: 122: 104: 16:(Redirected from 398: 370: 369: 346: 125: 118: 114: 111: 105: 103: 69:"Record locking" 62: 38: 30: 21: 406: 405: 401: 400: 399: 397: 396: 395: 376: 375: 374: 373: 367: 347: 343: 338: 326: 309: 274: 272:Exclusive locks 255: 219:in a database. 217:page level lock 202:database tables 198: 126: 115: 109: 106: 63: 61: 51: 39: 28: 23: 22: 18:Lock (database) 15: 12: 11: 5: 404: 394: 393: 388: 372: 371: 365: 340: 339: 337: 334: 333: 332: 325: 322: 308: 305: 292: 291: 288: 285: 273: 270: 254: 251: 197: 194: 172:data integrity 133:Record locking 128: 127: 42: 40: 33: 26: 9: 6: 4: 3: 2: 403: 392: 389: 387: 384: 383: 381: 368: 366:1-55860-190-2 362: 358: 354: 353: 345: 341: 331: 328: 327: 321: 317: 314: 304: 301: 297: 289: 286: 283: 282: 281: 279: 269: 266: 262: 260: 250: 248: 244: 239: 237: 232: 230: 225: 220: 218: 214: 209: 207: 203: 193: 191: 186: 184: 180: 175: 173: 168: 163: 160: 159:lock the file 155: 153: 149: 145: 140: 138: 134: 124: 121: 113: 110:December 2009 102: 99: 95: 92: 88: 85: 81: 78: 74: 71: â€“  70: 66: 65:Find sources: 59: 55: 49: 48: 43:This article 41: 37: 32: 31: 19: 351: 344: 318: 312: 310: 307:Shared locks 295: 293: 277: 275: 267: 263: 258: 256: 253:Use of locks 246: 240: 233: 228: 221: 216: 213:concurrently 210: 206:file locking 199: 187: 178: 176: 166: 164: 156: 148:bank account 141: 132: 131: 116: 107: 97: 90: 83: 76: 64: 52:Please help 47:verification 44: 313:holder list 278:holder list 224:granularity 380:Categories 336:References 80:newspapers 179:isolation 324:See also 316:entity. 243:deadlock 190:Jim Gray 137:database 357:375–437 296:waiters 94:scholar 363:  259:grants 167:locked 152:record 96:  89:  82:  75:  67:  234:In a 101:JSTOR 87:books 361:ISBN 300:FIFO 183:ACID 144:bank 73:news 236:SQL 56:by 382:: 359:, 192:. 185:. 174:. 123:) 117:( 112:) 108:( 98:· 91:· 84:· 77:· 50:. 20:)

Index

Lock (database)

verification
improve this article
adding citations to reliable sources
"Record locking"
news
newspapers
books
scholar
JSTOR
Learn how and when to remove this message
database
bank
bank account
record
lock the file
data integrity
ACID
Jim Gray
database tables
file locking
concurrently
granularity
SQL
deadlock
FIFO
Readers–writer lock
Distributed Transaction Processing: Concepts and Techniques
375–437

Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.

↑