Peter, you will get there some day.
On Fri, Aug 28, 2009 at 8: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. > > 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 -~----------~----~----~----~------~----~------~--~---
