home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / database / 6271 < prev    next >
Encoding:
Internet Message Format  |  1992-08-23  |  2.1 KB
  1. Xref: sparky comp.databases:6271 comp.databases.theory:378
  2. Newsgroups: comp.databases,comp.databases.theory
  3. Path: sparky!uunet!decwrl!world!edwards
  4. From: edwards@world.std.com (Jonathan Edwards)
  5. Subject: How to make a relational queue
  6. Message-ID: <BtGon0.KsF@world.std.com>
  7. Organization: The World Public Access UNIX, Brookline, MA
  8. Date: Mon, 24 Aug 1992 00:13:48 GMT
  9. Lines: 36
  10.  
  11. Well, my previous post turned up no adequate solutions.
  12. In fact, it may not be possible at all. This is such a damning conclusion
  13. (at least to me) that I feel obliged to post my conclusion in the hope
  14. that someone will contradict me.
  15.  
  16. The problem is implementing a FIFO queue as a relational table. Lets assume
  17. that there is a column containing the datetime of arrival in the queue to
  18. provide the correct ordering. The tricky part is to come up with a way of
  19. removing the oldest row in the queue. Constraints: there are many dequeuers
  20. running asynchronously, and each row must go to only ONE of them.
  21. Further constraint: TRANSACTIONS. Dequeuing is just one operation in a
  22. transaction that might take minutes. The entry must be returned to the queue
  23. automatically if the transaction aborts or the system fails.
  24.  
  25. The obvious approach is to do a SELECT MIN(datetime) followed by a DELETE.
  26. But what if someone else has already dequeued that row but not yet commited
  27. their transaction? We can't wait for the end of the transaction. So we
  28. could specify that we don't want to wait on this lock and retry the operation.
  29. We could retry by issuing a 
  30. SELECT MIN(datetime) WHERE datetime > locked-item-datetime.
  31. [I don't know SQL from shinola, so pardon my syntax]
  32. We iterate over all uncommited dequeues till we find a winner.
  33.  
  34. But I think this won't work, at least on RDB/VMS. As I understand it,
  35. RDB puts a read-lock on all rows visited by a transaction, so that our first
  36. SELECT statement would fail with a lock conflict. Thus we have no way of
  37. finding out just what the 'locked-item-datetime' is, because we can't even
  38. look at it.
  39.  
  40. Am I missing something? Do other databases permit more lenient locking to
  41. allow this? Thanks, Jonathan
  42.  
  43.  
  44.  
  45.  
  46.  
  47.