home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / database / sybase / 613 < prev    next >
Encoding:
Text File  |  1993-01-06  |  2.5 KB  |  68 lines
  1. Newsgroups: comp.databases.sybase
  2. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!paladin.american.edu!howland.reston.ans.net!usc!sol.ctr.columbia.edu!destroyer!cs.ubc.ca!newsserver.sfu.ca!sfu.ca!wolfgang
  3. From: wolfgang@fraser.sfu.ca (Wolfgang Richter)
  4. Subject: Re: Explicitly lock table
  5. Message-ID: <wolfgang.726345772@sfu.ca>
  6. Sender: news@sfu.ca
  7. Organization: Simon Fraser University, Burnaby, B.C., Canada
  8. References: <35833.salter@magnus.acs.ohio-state.edu>
  9. Date: Wed, 6 Jan 1993 18:42:52 GMT
  10. Lines: 56
  11.  
  12. "John Salter"  <salter@magnus.acs.ohio-state.edu> writes:
  13.  
  14.  
  15. >Is is possible to explicitly lock a table in Sybase to prevent
  16. >other users from inserting into table for a very short time?  If
  17. >so, how is it done?  Thanks.
  18.  
  19. Here is a repost of information that I gleaned from this newsgroup
  20. some time ago.
  21.  
  22. So far, the best solution that I have come across was supplied by Scott
  23. Elliott of AT&T Network Systems.  I have implemented his method and it works
  24. fine.  Here is what needs to be done:
  25.  
  26.   declare @id
  27.   begin transaction
  28.     if not exists (select * from table HOLDLOCK where id=@id)
  29.       begin
  30.         insert into table  values (@id,...)
  31.           .
  32.           .
  33.           .
  34.       end
  35.   commit transaction
  36.  
  37. If two users execute this at the same time, the following will happen:
  38.  
  39. User 1 and User 2 acquire shared locks on the table. They will each
  40. hold these locks until the end of the transaction (thanks to the HOLDLOCK
  41. keyword).  User 1 will request an exclusive lock on the table in order 
  42. to insert the new row.  He will be blocked because User 2 still holds a
  43. shared lock!  User 2 will now request an exclusive lock to insert a row
  44. also.  He is also blocked since User 1 still holds his shared lock.  We
  45. now have DEADLOCK!!!!  Sybase will then choose a victim and abort one
  46. of the transactions.  End result:  ONLY 1 USER HAS ADDED THE ROW.  You
  47. should also include some code to check the return value of the transaction
  48. to see if it was rolled back due to deadlock.  If so, repeat the request.
  49.  
  50.  
  51. Good Luck...
  52. -- 
  53.  
  54.  
  55.    +-------------------------------------------------------------------+
  56.    |   Stuart A. Stakoff           |      sstakoff@csfb1.fir.fbc.com   |
  57.    |   First Boston Corporation    |                                   |
  58.    |   (212)909-4926               |      (212)688-0913 - FAX          |
  59.    +------------------------------------------------------------------+
  60.  
  61. -- 
  62. -- Wolfgang Richter (e-mail: wolfgang@sfu.ca)
  63. -- Academic Computing Services
  64. -- Simon Fraser University
  65. -- Burnaby, B.C.
  66. -- Canada V5A 1S6
  67. -- Phone: 604-291-4449
  68.