On Sat, Aug 8, 2009 at 2:50 AM, cody koeninger <c...@koeninger.org> wrote:
> > Assuming people aren't patching clojure ala dave griffith's external > transactions patch in the group files, what are people doing in > practice to durably store the state of refs? > > Storing within a transaction and somehow ensuring your store operation > is idempotent (not to mention reversible)? > Sending off an agent from a transaction and not worrying about race > conditions? > Forgoing the use of STM in favor of locks + try / catch? > > I'm not so much asking about what particular store (RDBMS, prn to a > file, whatever) is being used, as I am curious what kind of > coordination is being used. In one current project, I have a macro (transaction & body) and some functions that create a weakly ACID file-transaction concept. A function transaction-file is called to convert a file object into the file to actually write, which will come back as a temp file if inside a transaction, and add that temp file to a list the transaction maintains. The transaction macro wraps the body with a bit of preamble code that sets up an atom used to build this list (and whose non-nil state informs the transaction-file function) and a post-amble that renames the original files, renames the temp files over them, and then deletes the original files. The post-amble is NOT in a finally block, so if an exception is thrown, the files are NOT replaced. A cleanup thread periodically kills temporary files that are "too old". This is entirely orthogonal to clojure's dosync. Strengths: * Changes to several files can be done "atomically", at least as far as the one Clojure thread is concerned. * Barring the unlikely event of something going wrong during the final renamings, changes to files either happen or don't happen. * The old version is never destroyed until the new version is safely in place with the old name. So if something does go pear-shaped, manual recovery is possible by a knowledgeable user. Weaknesses: * Separately changing the same file twice in a single transaction won't work. It would be nice to have a persistence framework in Clojure that was part of the core and provided some degree of ACID-like safety, with some sort of dosync-like wrapper, perhaps around arbitrary file operations, perhaps only around some system for serializing and deserializing Clojure objects. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
