This probably comes back to divergent requirements. Strict durability is much too expensive for what I need to do. For me the more important thing is that whatever authoritative data lives on disk is consistent with the application transaction boundaries. This means that I need to tag persistent refs as dirty or increment a version number when an STM transaction commits, so that when they are evicted from cache or a consistent snapshot is written to disk, I know what to write out. Another simplifying requirement is that I don't have to worry about different database domains for persistent refs. The application is organized around a single database that serves as a persistent store for application domain data.
-Per On Fri, Sep 24, 2010 at 10:40 AM, Alyssa Kwan <alyssa.c.k...@gmail.com> wrote: > Ah. I thought we were discussing prefs, or datoms (durable atoms), as > I would call them. Because datoms are only synchronous but not > coordinated, there's no transaction boundary. (More accurately, the > swap! is the transaction boundary, much like auto-commit.) dosync has > no effect on datoms. > > drefs, being coordinated, do require a transaction boundary. However, > I don't think it's possible without modifying LockingTransaction. > It's bad enough that the current implementation has 2PC against ACID > resources wrapped inside of a 1PC STM transaction. To place the > durable write outside of the 1PC would be much less safe. dosync > enforces a global transaction order. If writes were outside > LockingTransaction.run(), the order could (and probably would) be > different between in-memory resources and durable resources. For > ultimate safety, we need to be even more intrusive and add a prepare > phase to the STM. > > On Sep 23, 11:05 pm, Per Vognsen <per.vogn...@gmail.com> wrote: >> On Thu, Sep 23, 2010 at 8:16 PM, Alyssa Kwan <alyssa.c.k...@gmail.com> wrote: >> > There's no need for any transaction boundary; you just >> > have to make sure that compareAndSet does a durable swap. >> >> I had the chance to read your code today. You have a transaction >> boundary in DRef.set() which is called by LockingTransaction.run() at >> commit time. My point was that if you weren't intrusively modifying >> LockingTransaction.java you would need to take care of that somewhere >> else, the most obvious place being a dosync wrapper form. All you >> would need is a seq of 'vals' returned on a commited run(). That would >> also be useful for application-side transaction logging, etc. >> >> -Per > > -- > 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 -- 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
