I was about to say that. There's no need for the id's to be "contiguous", only to get them to grow to preserve ordering. If you can find a way in your design to increment the atom each time a transaction is retried then you would preserve ordering. The last value would be the one used in the "final" attempt.
Replaying of transaction should be based on the sort order of ids, not on sequentially incrementing the id value. I lack time to look how it would be expressed in Clojure however... It's not obvious to me yet that you can increment the atom within a dosync without getting also the atom change rolled back before the next attempt if STM decides to retry the transaction. If this is not possible then you could just use a simple Java object with a synchronized function to obtain different growing values. That would be a mutable object out of the STM scope so any retry would obtain a new value. When you reload transactions from existing persisted data, you just create the Java object with a seed number that does not conflict with the biggest value. (I assume here that you can add stuff to your journal-based persistence after a reload). Luc On Fri, 2009-12-04 at 08:06 -0800, David Brown wrote: > On Fri, Dec 04, 2009 at 03:15:28PM +0200, Sergey Didenko wrote: > > >However it looks interesting, "(dosync (alter myref inc))" takes much longer > > If your var is independent, how about using an atom? > > (swap! myatom inc) > > seems to be about 5-10 times faster than a dosync/ref on my Linux machine. > > David > -- 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
