I guess that depends on what you are trying to achieve, e.g. what degree of durability, consistency etc. you need.
What you describe sounds like you are basically beginning to write your own local database. Doing that well involves *hugh* amounts of tricky code, like ensuring data consistency in rare cases when the OS crashes / the machine loses power etc. Your approach also means your actor can never fail over to a different (virtual) machine. And talking of speed, I would be wary of guessing speed-ups without actual measurements, especially under load. So while you probably could get a solution based on local storage to work, it is likely to be far more work than it looks initially, be a pain to maintain, and is likely to fail in esoteric ways at unexpected times ;-) - Arno Am 12.02.2016 um 09:08 schrieb Chelios: > 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.
