the biggest issue i can think of is that you have a risk of data
inconsistency. for example:
1. a customer sends a command to your actor
2. the actor processes the command, persists an event (writing its state
locally), and replies to the customer
3. before the actor can flush the event to the remote database, it crashes.
4. you revive the actor on a different host (say the original host needs
maintenance) and the new actor incarnation loads the state from the
remote database
5. now the event from step 2 has disappeared.
whether or not this possibility is ok depends on your business requirements.
i agree with Arno that the cost/benefit tradeoff is not worth it. are
you really so memory constrained that you need to write all this code?
will writing to local storage really be that much faster than writing to
a database? keep in mind that for local storage in order to maintain
consistency you'll need to fdatasync() for every event, whereas with a
distributed database you can get away with writeback as long as you
write to some set of nodes W where W > 1.
but you should quantify and measure it if you don't believe me :)
-Michael
On 02/12/16 00:08, Chelios wrote:
Guys !!! Any help ?
On Thursday, February 11, 2016 at 1:23:59 AM UTC+11, Chelios wrote:
Hi Guys,
I've got an Eventsourcing & CQRS based application. Not using DDD
or Akka persistence (because of certain restrictions).
Has anyone tried storing the *State* of an *Actor* to local file
system instead into a remote database (Like snapshotting in
Akka-persistence) ?
I was thinking of doing the following
1. *Command* arrives at *ActorA*
2. *ActorA* checks if it has a serialized *State* on local file
system, if yes, it de-serializes the *State* and processes the
*Command*, and then *ActorA *flushes it's *State* to disk holding
only directory reference to the updated local serialized *State*.
3. If *State* does not exists on local file system then it replays
all *Event*s from the database, process the *Command*,and then
*ActorA *flushes it's *State* to disk holding only directory
reference to the updated local serialized *State*.
I see the following benefits in doing this
1. Much less memory usage since the state is not being kept in
memory.
2. I don't have to worry much about killing Actors in real time
since the State is only holding a String which is a reference
to the locally serialized State's location and creating Actors
is cheap.
3. Reduced trips to the database.
4. It's faster to read data locally since we know the location of
the Serialized State, so probably help in building a speedy app :)
Am I seeing this right ? Or there are some problems that I have
not thought of ? Any experience with this ?
Chel
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google
Groups "Akka User List" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to akka-user+unsubscr...@googlegroups.com
<mailto:akka-user+unsubscr...@googlegroups.com>.
To post to this group, send email to akka-user@googlegroups.com
<mailto:akka-user@googlegroups.com>.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
--
Read the docs: http://akka.io/docs/
Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
