On Fri, Aug 28, 2009 at 4:45 AM, peter veentjer<alarmnum...@gmail.com> wrote: > >> 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. >
And I'm not arguing against fast STMs :) Just explaining that, because my ideas about STM (you shouldn't need a transaction to see a consistent object) required persistent data structures and a language where they were pervasive and idiomatic, I ended up with a whole language and an approach that includes certain efficiencies, which, I think, will hold me (and Clojure users) until I (or someone) get around to perf-tuning the STM, which is something I've spent no time on at all. You know the old saws, "make it right, then make it fast", "premature optimization is the root of all evil in programming"... I'm still working on the "make it right" phase :) Rich > 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 -~----------~----~----~----~------~----~------~--~---
