>It checks the value against memory. If it's >the same, commit data store changes. If not, retry after refreshing >memory with the current contents of the store.
May I suggest we take a page from the CouchDB book here? In addition to having a "id" each ref also has a revision id. Let's say the id for my ref is "foo". Then the first time I modify that ref the revid becomes "1-foo". From there the 1- is incremented by one on each writing transaction. This allows for a single string load & compare for each change, instead of reading the entire contents of the ref. That combined with CouchDB's copy-on-write means that you can kill a couchDB process mid-execution, and then restart it without any data corruption at all. If we find a way to do external persistence...that would be awesome, I can think of several use cases for it right now. Timothy -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
