> No. I don't want to use transactions for workflow. I don't want > blocking transactions. I don't want read tracking.
With multiverse it depends on the engine being used and the settings on the transaction. And readonly transactions also don't track reads. > > And since Clojure is using MVCC, does it also suffer from a broken > > serialized isolation > > level?http://pveentjer.wordpress.com/2008/10/04/breaking-oracle-serializable/ > > Clojure doesn't promise any "serialized isolation level". It provides > snapshot isolation, which is subject to write skew, as better > described here: > > http://en.wikipedia.org/wiki/Snapshot_isolation > > In order to prevent write skew, Clojure provides the 'ensure' > operation which can be used for reads to non-written refs that form > part of the integrity promise of a transaction, without incurring that > overhead all the time for reads that do not. I much prefer having this > fine-grained choice. I'll have a look at it. > > > And what kind of performance do you get with clojure? > > I'll let other people answer that from their experience, but only say > that it is probably too general a question to be particularly > meaningful. True. > Clojure's STM is part of a holistic language design where > people will normally be programming with immutable persistent > composite data structures. Getting a consistent view of such a data > structure doesn't require a transaction at all, so that is much faster > than other strategies. When 'changing' a data structure, you read it > from the ref once and then structural changes do not involve the STM > or refs. Store it back in the ref when done. Thus the granularity of > transactions is coarse and the number of ref interactions involved > small. These are not things you'll see when timing pounding an integer > in a transactional ref in a tight loop, but matter greatly in > practice, IMO. I partly agree. One of my design guidelines is that one should not have to pay for what is not being used. One of the things I'm focussing on is making the transaction as fast as possible for any length. I'm working on a system that advices the creation of a transaction with the maximum number of attached objects. I have a transaction optimised for a single attachment (5+M transactions/ second on a single core), for a small number of attachments (so using an array to store attached items to reduce object creation) and one for a large number of attachments (so using an expensive hashmap). The later one also is going to get a parallel commit (so obtaining locks/checking for isolation problems.. and doing the write) to make effective use of the cores and speed up the commit of larger transactions. So I'm working on all levels to make it as fast as possible and pounding on an intref is something that helps to find a subset of problem areas. And if something is fast enough, people don't try to work around it.. so it also helps to reduce complexity imho. But again, I think that clojure is doing a great job. You have a cool language, a cool stm, an active community and a lot of exposure. So you are where I want to be :) > Rich > > PS: > > I think that Clojure really did a great job with adding STM to the > > language. I have been working on multiverse for almost a year, > > and I only have an stm. With Clojure the STM is one of the many > > features provided. > > > > On Mon, Jul 13, 2009 at 2:07 AM, Vagif Verdi<vagif.ve...@gmail.com> wrote: > > > > > Potentially interesting library for clojurians. Java STM > > > > implementation:http://www.deucestm.org/ > > > > -- > > > Venlig hilsen / Kind regards, > > > Christian Vest Hansen. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
