Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


Tip of the Day
Language: SQL Server
Expertise: Beginner
Mar 24, 1997

Lock Conflicts

Question:
Our system is experiencing several lock conflicts. We've got a consultant looking at the details, but I was hoping you could explain what's going on behind the scenes when records are locked.

Answer:
One of the many potential problem areas handled by a DBMS is concurrency control: making sure that as many users as possible have access to as much data as possible without sacrificing the integrity [accuracy] of the data. The most common means of ensuring integrity is the use of locks. Each DBMS implements locking in its own way, but there are four isolation levels that are defined by the SQL-92 standard. You, or your consultant, will have to decide the appropriate isolation level at either the application or transaction level. The strictest isolation level (Serializable) guarantees the best data integrity, but also has the least concurrency; that is, users will get locked out more often. On the other end of the scale, the Read Uncommitted isolation level provides the greatest concurrency, but can sacrifice data integrity if used inappropriately. When you're experiencing lock conflicts on your system, the isolation level could be one of the problems. Sometimes the solution is to adjust your application programs to reflect an understanding of the locking scheme of your particular DBMS.

DevX Pro
 
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date