home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / database / 6719 < prev    next >
Encoding:
Internet Message Format  |  1992-09-13  |  2.9 KB
  1. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!spool.mu.edu!agate!rsoft!mindlink!a269
  2. From: Mischa_Sandberg@mindlink.bc.ca (Mischa Sandberg)
  3. Newsgroups: comp.databases
  4. Subject: Re: looking for record locking techniques
  5. Message-ID: <15114@mindlink.bc.ca>
  6. Date: 14 Sep 92 09:22:21 GMT
  7. Organization: MIND LINK! - British Columbia, Canada
  8. Distribution: world
  9. Lines: 54
  10.  
  11. > James H. Coombs writes:
  12. > 
  13. > Msg-ID: <1992Sep13.012730.9579@cs.brown.edu>
  14. > Posted: Sun, 13 Sep 1992 01:27:3
  15. > 
  16. > Org.  : IRIS - Brown University
  17. > 
  18. > In article <15077@mindlink.bc.ca> Mischa_Sandberg@mindlink.bc.ca (Mischa
  19. > Sandberg) writes:
  20. > 
  21. > >Would you consider moving into the 90's with a non-locking database?
  22. > >Perhaps you've heard of chronological databases, such as (old and hairy)
  23. > >LOGIX and of late, InterBase. My company does custom distributed
  24. > >wide-area networks, with frequent interruptions, and non-locking
  25. > >schemes beat locking ones, for performance and reliability. The
  26. > 
  27. > Could you give us references?  Or a description of the techniques?  You
  28. > know, in the spirit of the Internet and not advertising?
  29. > 
  30. > --Jim
  31.  
  32. Sorry, wasn't advertising. Last ref I have for Interbase is (408)431-5120.
  33. Last ref I have for LOGIX is (617)864-0137. Last major batch of articles
  34. I saw on it was in IEEE Reliable Systems Symposium (conf. proc) 1990.
  35. Sorry not to have more specifics on hand; go to your nearest univ. library
  36. and hit the IEEE journals on distributed databases, or SIGMOD proceedings.
  37.  
  38. Description of techniques? Every record has an absolute timestamp.
  39. You keep old versions (think of the timestamp as an extension of
  40. the primary key) back at least as far as the oldest pending reference.
  41. All transactions are allowed to proceed; at the end of a transaction,
  42. the timestamps as of the start of the transaction are all compared with
  43. the current timestamps of each row. If they differ, the transaction
  44. rolls back and restarts; and "tough luck what now?"
  45. is sent back to the client, after (n) restarts. In any case,
  46. high-activity queries and low-activity updates don't interfere with
  47. one another; "select count(*) from TABLE" can merrily chug along
  48. searching for rows with timestamps no greater than asof the start
  49. of the query, while new versions (and deletion markers) with fresher
  50. timestamps are inserted.
  51.  
  52. Depends upon how you implement it, but your transaction log and your
  53. pending versions can be the same thing. Consistent backups can be running
  54. while the database is being updated. Also depends on how version
  55. garbage-collection is done, but you can request a view of a table "asof" a
  56. given timestamp. This was true for LOGIX; not sure what depth of versions
  57. is kept in Interbase (Nigel?)
  58. --
  59. Mischa Sandberg ... Mischa_Sandberg@mindlink.bc.ca
  60.                  or uunet!van-bc!rsoft!mindlink!Mischa_Sandberg
  61. *-*-*-*-*-*-*-*-*-*-*
  62. Engineers think equations are an approximation of reality.
  63. Physicists think reality is an approximation of the equations.
  64. Mathematicians never make the connection.
  65.