One thing I like about Akka is the idea of combining lock-free actors
with lock-free and deadlock-free STM. With that combination you should
be free of problems with deadlocks and race conditions. It comes for the
price of the added complexity incurred by asynchronous communication
between actors, I know ...
Nevertheless, the idea of optimistic locking and deadlock-free commits
is nice IMHO. If this were added to JavaSpaces and someone felt for the
actor approach, everything would be there to implement actors with
JavaSpaces. No more blocking reads or takes. And the STM in Akka does
not allow to register for events when data changes. That functionality
was part of JavaSpaces to begin with.
Regards, Oliver
On 22.10.2011 09:27, Dan Creswell wrote:
Hey Patrick,
On 21 October 2011 21:44, Patrick Logan<[email protected]> wrote:
Hi all,
I was involved in a jini/javaspaces project five years ago, with good
success. Recently I've been trying Scala including the Akka "actors"
library.
Akka has promise but has fewer capabilities than Jini and Javaspaces,
and is certainly less mature.
I am wondering if anyone on the River list has been using Akka with or
without Scala?
Yes and I know some other people doing similar. Quite a lot of
interest in the banks....
Might folks see River as a more mature, capable system worthy of a
revival now that Scala and Akka are attracting a lot of interest in a
related distributed programming model?
I'm afraid I think it's unlikely to help bridge the gap for several reasons:
(1) The programming models are substantially different -
single-threaded, message passing with queues and no clear
differentiation of remote ( I'll say a bit more about that in a
minute.) from local vs services and any threading model you like.
(2) I'll no doubt get into trouble for saying this: The Akka folks are
making all the same mistakes made by others previously. In particular
they've attempted uniform I/O models for different grades of
consistency, they consider various bits and pieces as optimisations
rather than critical requirements for stability/maintainability and
they're attempting to retrofit high availability and replication to a
non-distributed memory model (something that Terracotta have attempted
for example).
