Enterprise Beans vs Actors - some considerations:
- Services are singletons, mostly
- Every operation is performed asynchronously, with the implied hope that by the time someone asks for the result, the underlying operation will have finished.
- Spring operation methods' become message classes in Akka actor model read more...
Wrap all of the case classes for a particular actor in a protocol object as a nice way of isolating those case classes in their own sub-scope, even if all the actors belong to the same package. read more...
As I said before, methods become message/command classes. In this post the author made a nice suggestion to send the replier actor reference as parameter on message.
While running into a blocking api of the repository, which might be the only thing you can do, depending on your database driver, is possible to go for an async api, i.e. returning Futures. In the actor you would then instead pipe the result of the Future to the sender. read mode...
Although actor based concurrency doesn't fit with transactional operations out of the box but that doesn't stop you from using actors that way if you play nicely with the persistence layer. If you can guarantee that the insert ( write ) is atomic then you can safely have a pool of actors doing it for you. Normally databases have a thread safe read so find should also work as expected. Apart from that if the insert is not threadsafe, you can have one single WriteActor dedicated simply for write operations and the sequential processing of messages will ensure atomicity for you. read more...
- No more out of memory issues because of too many messages in the mailboxes.
- We only create as much work as is actually needed – Kanban style! This also means minimal liability for the workers. If a node goes down, we only loose the messages that were currently worked on.
- Completely non-blocking, fully utilise your resources.
- The actors involved can still receive other messages, e.g. to stop them.
- Distribute work across the cluster with ease. Fully utilize all your boxes so you don’t need more than necessary.
- Scale up and down dynamically by simply adding more nodes to the cluster during the execution of an epic. The workers on that node will happily join in with the other workers and start kicking off work to speed up the execution. Afterwards you can shut it down again to save some pesos. Cloud computing at it’s best!
- It’s not a polling model where you have the overhead that workers regularly ask for work. They only ask when there’s actually work available.
- Easy to use: simply instantiate a master, give it a name and implement doWork on the worker.