December 30, 2012 at 7:01 am
Question1: How can a user, say User1, be able to lock a row, say Row1, and any dependent rows, say Row11, Row12, until changes are made to the specific row by User1
Question2: If another user, say User2, wants to access Row1 or Row11, Row12, when these rows are locked by User1, is there a way to let User1 know about it and in the worst case force the unlock, or have some kind of timeout whne User1 is inactive
Thanks,
John
December 30, 2012 at 10:12 pm
YOu are basically asking about LOck mechanism. in your case when DML operation performs then exclusive locks are used by sql engine and it can get eslcalated from row level upto table level (decided by sql server internally) based on the amount of data that query is handling. see http://blogs.msdn.com/b/sqlserverstorageengine/archive/2006/05/17/lock-escalation.aspx
-------Bhuvnesh----------
I work only to learn Sql Server...though my company pays me for getting their stuff done;-)
December 31, 2012 at 1:37 am
Thanks for your reply and suggestion article. I am doing some reading in the mean time.
One of the problems which I am trying to solve is once a user accesses (checks out) a secific record in a table, I would like all subsequent accesses to this specific record by other users to result in a message saying that the record has ben checked out by UserA and not allow changes if UserA does not release the record.
December 31, 2012 at 1:54 am
For that you'd need to manually reimplement SQL's locking mechanism, probably with a locking table, manual checks, manual notifications in all code that you have. You then need to consider all the complications of rows getting locked but never unlocked, etc. It's a hell of a lot of work and very easy to get wrong.
iirc there's a chapter on implementing something like this in Expert SQL Server 2005 Development (yes, the 2005 version)
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
December 31, 2012 at 2:57 am
Many thanks for your reply Gail,
I appreciate the fact that it would be easy to mess up. If a user needs to work on a specific record for a few minutes and during this time we want to disallow any modifications to the record can we introduce an extra boolean field in the table which would indicate whether the record is checked out or not?
John
December 31, 2012 at 3:04 am
john 60195 (12/31/2012)
I appreciate the fact that it would be easy to mess up. If a user needs to work on a specific record for a few minutes and during this time we want to disallow any modifications to the record can we introduce an extra boolean field in the table which would indicate whether the record is checked out or not?
You can.
Every single piece of code that you have must then honour and check that (and there's no way SQL can enforce that, you will have to in your code). You need to take great care that two connections can't both think they locked the record (very easy to do if you haven't got the isolation levels, locks and transactions exactly right in your locking code). You need some process/method to unlock rows that have somehow remained locked even though the user is done (many, many possible causes) while not unlocking rows that the users are just taking their time over.
You're looking at massive amounts of development here, huge testing requirements and very likely a lot of related bugs.
Is it really, absolutely necessary to reimplement the database locking methodology yourself? Is it worth the time and effort?
Grab that book I mentioned and have a read through the chapter on this. It's an entire chapter devoted to the myriad ways of getting this kind of process wrong.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
December 31, 2012 at 3:04 am
john 60195 (12/31/2012)
One of the problems which I am trying to solve is once a user accesses (checks out) a secific record in a table, I would like all subsequent accesses to this specific record by other users to result in a message saying that the record has ben checked out by UserA and not allow changes if UserA does not release the record.
Technically this is possible (as gail commented above ) but not recommended. Can you share the actual requirement(businees requirement) so that we might help you.
-------Bhuvnesh----------
I work only to learn Sql Server...though my company pays me for getting their stuff done;-)
December 31, 2012 at 5:06 am
Many thanks for your input to both of you.
I have developed a Dental Practice Management Software package (www.VisualDentist.com) using Access and Jet. While this setup is adequate for a small to medium Dental Practice it is not for a large one, hence the interest to use SQL Server.
The problem which I would like to address deals with accessing the dental record of a patient. This includes information relating to the graphical representation, work details, personal details, financial details etc. Assume the Patient records are in tblPatient (let's forget for the time being any one-to-many relationships with other tables). If a user accesses a record (a patient) in tblPatient, the user will have in front of him a graphical picture of teeth. If the user keeps this picture on his screen for some time (say 5 minutes) and subsequently makes a change, I would like any other users accessing this record during those 5 minutes, to be alerted that the record is under modification and maybe prevented from making any changes until the original user finishes with this patient record.
Does this help?
Regards,
John
December 31, 2012 at 5:35 am
Everything I've said stands. You are looking at a huge amount of development and testing and probably a tonne of bugs and irritations. This isn't a 5 minute job.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
December 31, 2012 at 6:41 am
Gail, have taken your advice seriously. I will see whether the functionality can be modified to avoid the headaches.
Thanks,
John
December 31, 2012 at 9:33 am
MS provides "sp_getapplock", and the corresponding "sp_releaseapplock", to help you do this. With them, you can leverage SQL's already-built-and-tested locking mechanisms for your own logical locking. You also want to look at APPLOCK_TEST() (and maybe APPLOCK_MODE()).
SQL DBA,SQL Server MVP(07, 08, 09) A socialist is someone who will give you the shirt off *someone else's* back.
December 31, 2012 at 11:17 am
You could take another approach and move the concept of locking or checking out a record and subsequent notifications of said lock to a middle tier, perhaps a WCF service or something similar. That would be far simpler, than reinventing the locking mechanisms and all that it entails.
December 31, 2012 at 12:24 pm
Scott, the trouble with sp_applock is that it's designed around single user - single process aspects. My understanding of the OP's question revolves around multiple dentists accessing multiple clients simultaneously, but he wants to make sure that none can step on the other's work.
Instead of rebuilding the wheel, there's another method of dealing with this but I personally hate it, because like the other method, so many things can go wrong. Just less moving parts.
Look into Transactions and Serializable isolation. What you'll be looking to do is have the application code control your transactions (and do NOT share connections) so that you begin this process by setting the connection to serializable isolation, then opening a transaction, then reading the particular rows you need from all tables. This share-locks them to that account. But, what you do during that read is force the exclusive lock via join hints.
From there, you let them do their work and close the transaction when they're done.
Be aware, however, that this is NOT as granular as you think it is. This approach can hose you up very quickly depending on how much data you're pulling, as you won't be doing just row locks, but page and table locks because of the way memory and data storage is managed in SQL Server. It requires JUST as much testing and even more optimization than the other method to make sure you're locking as little as possible for each user's access.
So, since we've been telling you just how hard this could be, let me make a recommendation for a much easier to approach method that is less likely to shoot you in both feet.
Start with adding a last access datetime column to all the tables that you're looking to lock for a particular user's modification. Pull said data for the user. When they choose to edit any data, have the system go through and check to make sure noone's tried to edit in the last five minutes via this column, then update all the records just for the datetime piece. Have your code disallow editing to proceed blindly after five minutes, where it would have to go through and re-check the timestamps (to make sure another user didn't come in while they got their coffee and talked to the assistant) to make sure their allowable edits are still valid. If they're still allowed, let them commit the changes.
Does this do exactly what you were looking for? No. But it is MUCH easier to implement and much less likely to end up with your system locked out requiring massive developer involvement to get the production system to re-release. At worst, everyone just has to wait five minutes.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
December 31, 2012 at 12:36 pm
You could also add an "in-use" column to each row which is set when someone accesses it, and unset when they close it and/or after a certain period of time has elapsed.
SQL DBA,SQL Server MVP(07, 08, 09) A socialist is someone who will give you the shirt off *someone else's* back.
January 3, 2013 at 6:49 am
Many thanks for your replies. I did some research and found out the following:
Scott regarding "sp_getapplock", it appears that from what I read, it should not be the first choice, especially if the record will be checked out for some time.
Craig are you referring to something like this, where there should be a check if the record is not committed in a reasonable amount of time?
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
BEGIN TRANSACTION;
select * from ...
update ...
COMMIT TRANSACTION;
Viewing 15 posts - 1 through 15 (of 37 total)
You must be logged in to reply to this topic. Login to reply