I had a quick peek at the stm paper of mark volkmann
This function takes a Ref. It prevents other transactions from setting an in-transaction value for the Ref, which also prevents them from committing a new value. This can be used to avoid write skew. It also helps avoid retries due to write conflicts on the Ref. The current transaction will be able to set a new value for the Ref later in the transaction as long as other transactions haven't called ensure on the same Ref. This calls the touch method on the Ref which passes the Ref object to the doEnsure method of the LockingTransaction object for the current thread. That acquires a read lock for the Ref which is held until the transaction commits or until the Ref is set with ref-set or alter later in the transaction try. So it looks like it is an encounter time ensure. On Sep 14, 10:05 pm, peter veentjer <alarmnum...@gmail.com> wrote: > Ok, I have a 1 and 2 :) > > So is it pessimistic or optimistic? So encounter time ensure or commit > time ensure? > > On Sep 14, 9:36 pm, Stuart Halloway <stuart.hallo...@gmail.com> wrote: > > > Actually, the second one is basically it. (Except that I don't know the > > Oracle reference, so can't speak to that.) > > > Stu > > > > The first one is correct. > > > > On Tue, Sep 14, 2010 at 3:22 PM, peter veentjer <alarmnum...@gmail.com> > > > wrote: > > > I have got a question about the Clojure ensure and how it actually > > > works and the documentation doesn't provide enough information. > > > > I see a few different solutions: > > > > 1) An optimistic approach: Once a ref is 'ensured' it is included in > > > the conflict detection set. This means that the approach is still > > > completely optimistic because 2 concurrent transactions that have the > > > same ensured ref, one of them is going to fail when the transaction > > > wants to commit. This is a commit time ensure. > > > > 2) The other approach is a more pessimistic approach where a ref can > > > be protected against writes made by other transaction as soon as it is > > > ensured. It still allows reads to happen, but a write/ensure is going > > > to fail. It could be compared to a oracle 'select.. for update'. This > > > is an encounter time ensure. > > > > -- > > > 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
