Hi All,
I have two applications accessing a private database.
Feeder - Acts on events arriving from elsewhere and makes changes/additions to the data. Somewhere between once per day and hundreds per minute.
Admin - Presents reports on data and allows acknowledgement of states detected by Feeder. Acknowledgement results in deletion of records.
Both applications are in-house. Feeder will be running on or close to the server. Admin could be run anywhere on the estate but there will only be one copy of either component.
I need some way of locking out the feeder from making updates to the database while Admin is running.
I have seen in other comments:
BEGIN TRANSACTION
SELECT * FROM ATable (holdlock, tablockx) where 1 = 0
-- Do stuff for a while.
COMMIT TRANSACTION
If I run this from Admin am I right that Feeder will be locked out from any access to the table, even reading?
Why the 1 = 0? Is it to ensure we don't get any records back?
What if Admin gets switched off while the lock is in place? Can the lock be torn down?
How long will the lock hold? Admin may take an hour or more to process the results before committing its changes.
Would it be better to use a special record in a special table and hold a lock on that as a semaphore? If so how?
Thanks in advance. :)
Paul
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Save solutions to your questions, answers you’ve discovered through searching plus helpful articles in your personal knowledgebase for easy future access.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.
Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
As I said in my first comment:
Feeder will be locked out, but after a deadlock timeout you may get an error in feeder, but you can retry the transaction. Feeder should also do a begin transaction and commit transaction if more than one insert/update/delete is being done.
Detecting the lock is not something that is normally available. Transactions or queries should normally happen quickly. Again transaction isolation is the way to deal with this.
Thanks Kevin,
I do want Feeder to be locked out and this does do the job. I left it waiting for over an hour and it was still waiting. :) There wont be a deadlock as only one table is locked.
I just felt that this length of time was a little long for it to be incommunicado. I'd like to try to find a way to drop the timeout to a few minutes or check for a lock before going in. I'll do some further research
The feeder does all of its work in one transaction for exactly this reason, I want it to be locked out of the table.
Thanks for your help.
Paul
Business Accounts
Answer for Membership
by: kevin_uPosted on 2009-07-09 at 17:31:29ID: 24819566
1 = 0 is just as you say.
Feeder will be locked out, but after a deadlock timeout you may get an error in feeder, but you can retry the transaction. Feeder should also do a begin transaction and commit transaction if more than one insert/update/delete is being done.
If the connection is broken from admin, the lock is automatically released.
The lock will be held until Commit Transaction or Admin terminates or disconnects from ther server.
Special records are generally a pain .
The proper way to deal with this is to learn about transactions and transaction isolation levels. It allows one process to aquire an intact snapshot with little or no interference from the other processes. It involves using Begin transaction and Commit Transaction around your update processes. Transaction Isolation Levels determine whether Admin can receive records that are "dirty" (no commited) or not, therefore give you the consistancy of data across the tables that are updated.
http://msdn.microsoft.com/