Hi Oliver, Is it fair to say an Akka-based program should be free of deadlock and race conditions? They will show up in different ways, but will easily show up without a design that attempts to eliminate them. (Same with starvation, which can show up in STM at a lower level, but maybe more likely at a high level with distributed actors.) I think Akka could mature into a useful system, but it lags Jini in significant ways... which is really the point of my original question, why not go back to Jini and bring it forward in the Scala world as well as the Java world.
Also perhaps introducing optimistic locking and STM in new kinds of Jini-based services would have some applications. For example, rather than trying to augment Javaspaces with these mechanisms, they may be better applied to a shared, mutable data(base)(-ish) kind of service. -Patrick On Thu, Nov 17, 2011 at 1:40 PM, Oliver Plohmann <[email protected]> wrote: > 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). > >
