On Monday, December 10, 2012 3:17:27 PM UTC+1, Chas Emerick wrote:
>
> 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.
>
I am comparing this with a mutex-based solution, which is still the default
way to implement thread safety. Obviously, no problems with side effects
there.
>
> 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.
>
So again, I would like to see the benefit of an STM over a lock-based
solution. Read-heavy scenarios behave well with read/write locks and if
there's not much writing around, it's usually not too complex to be kept
under control with locks. So an STM-based solution would have to offer a)
less complexity due to no locks and b) not incur its own complexity while
dealing with side effects.
>
>
>> 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.
>
Usually you have a unit of work to complete. If any part of it involves
side effects, you'll need a mutex around it, and at that point the STM
brings nothing. Another frequent problem is having any kind of time-heavy
action, which you must make sure to execute only once (even if it is
retryable by nature). Every new problem I start to work with, I first think
long and hard how STM could fit into the picture; I have failed every time.
Mind that my company is an early Clojure adopter ("we remember when
#clojure channel had only 6 people in it" :)
>
> 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.
>
I'll definitely check it out, maybe it gives me good ideas for the future.
Thanks!
--
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
