On Monday, March 13, 2017 at 11:55:55 PM UTC+3, Rafał Krzewski wrote:
>
> If you are up to for an adventure, I recommend you to read "Life beyond
> Distributed Transactions"
>
>
cheers,
> Rafał
>
>
I know it's hard to believe but I'm interested in local transactions rather
than distributed.
Thanks for mentioning the saga technique. To my surprise I had already used
it without knowing. That is the first thing that comes in mind in certain
situations.
But saga by no means could provide a transaction guaranties. The
intermediate state is visible to third party during so called
That is how I've implemented it finally. Just store messages and restore
them when the result would become clear. The actor performs some data
management, so it should have confidence in own state before it could
proceed further messages.
But reducing actor activity to just message shuffling
On Sunday, February 19, 2017 at 10:53:01 PM UTC+3, Justin du coeur wrote:
>
> Do you mean literally calling "sleep()"?
>
I mean sleep as a thread state. Alternative is to save actor state somehow
and return thread to dispatcher so it can be reused. The dispatcher should
never bother the
I need to perform number of requests to different actors and sum them to
some response. An actor wrap all requests inside futures and compose them
to single. After that I suppose actor would be put in sleep until it
recovers all needed information (or timer runs out). What if I had hundreds
of
act the team on gitter or github.
>
> --
> Konrad `ktoso` Malawski
> Akka <http://akka.io> @ Lightbend <http://lightbend.com>
>
> On 13 January 2017 at 16:42:37, scala solist (scala...@gmail.com
> ) wrote:
>
> Sometimes you need to do coordinated work betwee
I'm using akka for desktop application multithreading, so I need only
simple akka features that works local. Unfortunately local-only features
are unwelcomed in new akka. So I would code some kind of hack like sending
local states of both actor to the third actor and suspending until it would
Sometimes you need to do coordinated work between actors and modify shared
state. The state in broad sense is separated by actors, there is no need to
share them all. But sometimes there is a need to share small chunk of state
and work with it with several actors. How it should be done in the
There is an obvious way to make mixins for actors: take *receive, preStart,
postStop* methods, override them and call super inside. Or make
*List[Receive]* and fold the list to single partial function. Things become
harder with the *become* method. I could modify it in such way that it
would
would also be to model backgammon board based on a
> Conflict Free Replicated Data type. If you solve that, then you could use
> Akka
> Distributed Data
> <http://doc.akka.io/docs/akka/current/scala/distributed-data.html> module.
>
> On Fri, Aug 5, 2016 at 3:24 P
For example, we would like to model the backgammon game with akka actors.
Both players are actors (either human or AI), there is also an actor that
rules the board and determines dice rolls for players. They all share the
single board. What is idiomatic way to have access to the board and to
I'm started to work with akka as scala actors become deprecated in favour
of akka. So I'm intrested only in local actor systems for now. What is
intended way to implement publisher subscriber template in akka?
Akka gives multiple choice, I found three already:
- Store subscribers manually
12 matches
Mail list logo
