On Dec 10, 2012, at 8:37 AM, Marko Topolnik wrote:
> It's true that STM is "all or nothing", but it is so over the scope of refs
> you choose. If there's some side-effecting bit you need to do somewhere,
> then clearly that's not going to fit within a transaction…but that bit will
> often fit just fine in a send-off to an agent provoked _by_ a transaction.
>
> send-off fails to be useful whenever you need the results within the
> transaction (quite often, that is).
I'm not aware of any system that provides transactional semantics in the face
of in-transaction side-effecting actions. If you can refer me to any, that'd
be great.
> > 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.
>
> If your task is purely computational and amenable to massive parallelization,
> you _should_ use agents whenever possible. STM provides for coordination in
> order to enforce consistency; unless all of your operations are commutative
> (in which case, you should probably be using agents anyway), a program using
> STM _will_ provoke retries and other means to route around ref contention.
> This is acceptable because STM is all about maintaining correctness in the
> face of concurrent mutation, and not necessarily about performance, aggregate
> throughput, and so on.
>
> But concurrency is all about performance and throughput. So where is the
> benefit of using correct, slow concurrent mutation? I guess in a
> write-seldom, read-often scenario.
Fundamentally, concurrency is about simultaneous independent computation.
Depending on the domain and computations involved, single-thread performance
and aggregate throughput can vary significantly.
Anyway, read-heavy applications are still the norm in most industrial settings,
despite the rise in popularity of write-scalable architectures.
> On the other hand, ref readers are _never_ blocked (regardless of what's
> going on on the write side), so the data in such refs is always accessible.
> This sounds like an ideal combination for "business logic" (as nebulous a
> term as that is) to me.
>
> Business logic almost always involves communication with outside systems
> (since it's usually about integration of many existing systems). Even if not,
> a scalable solution must be stateless (a prerequisite for cluster deployment)
> and any durable state must go into a single datasource common to all cluster
> nodes. Again, these datasources don't participate in an STM transaction.
> Maybe this would be a major route of improvement: integrate the STM with
> external datasource transactions. But this is still quite removed from the
> present.
I'm certain that particular set of requirements holds in certain settings, but
they are hardly universal.
If I may make a tenuous inference, it sounds like you're trying to fit every
state transition within an application into a transaction. If so, I'd
recommend the opposite: decomposing applications and their processes into
modular bags of state and treating them separately will lead to big wins —
including potentially being able to use e.g. STM in one place, and agents in
another, each interacting with the other as necessary.
Re: getting disparate datasources to participate in transactions, you might
want to take a look at Avout:
http://avout.io
I can't say I've used it, but it is at least an existence proof of the ability
of the Clojure STM model to be distributable.
Cheers,
- Chas
--
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
