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
