To give the full story, I should add that atoms are very natural to use and many concurrent use cases are covered by them alone. The combination of atom and immutable vector/map goes a long way and they are also useful even with mutable data, such as lazy-initialized singletons, resources that need to be re-acquired after failure, and other similar cases.
In general I can say that STM transactions of very fine granularity are easy to work with because they effortlessly intertwine with mutable data and side effects. On Monday, December 10, 2012 11:39:02 AM UTC+1, Marko Topolnik wrote: > > The very fact that there has been no reply to this for five days may mean > something. I can personally attest to STM being very difficult to put to > real-life use because there is always that one thing you absolutely need > for your problem, that is mutable and not transactional. Most of the time > it will have to do with an existing Java library, JDK not excluded. The > property of STM that it is an all-or-nothing commitment has been a > show-stopper for me every time I tried to use it. > > My guess is, if your task is something purely computational and amenable > to massive parallelization, you may have a go with STM; if it's just about > business logic accessible concurrently by many clients, you won't find it > workable. > > -- 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
