My Service Fabric actor can create some large data structure in memory during its work. I don't want to update reliable collection at the end of each method invocation.
Can I save my actor state by StateManager only in OnDeactivateAsync method and restore it in OnActivateAsync method? May I lose the state in this case?
You'll lose data if an actor, or its underlying service, or the node crashes. If you can afford to loose state or can rebuild it at Actor ActivateAsync you can just keep that structure as a class member. (like in a regular poco)
(posted as anwser)
Related
Why is persistence context called persistence context?
Is it context because it acts as a stepping stone until the object is permanently stored in db?
(Because context is a dynamic feeling from where to where rather than a static feeling?)
A context in computing terms is defined as follows:
In computer science, a task context is the minimal set of data used by a task that must be saved to allow a task to be interrupted, and later continued from the same point.
Context_(computing)
A persistence context is a specific context relating to database persistence. Just like any other context it will store required state relating to database persistence.
Is it context because it acts as a stepping stone until the object is permanently stored in db?
JPA works with transactions, sometimes this can appear hidden if using web frameworks that automatically begin and end the transaction for an http request. The persistence context will act as a kind of cache during a transaction storing any database reads. Any updates made are also saved to the context until the transaction is finished or you manually flush, at which point they will be persisted to the database.
I have a spring-boot app that exposes a REST api. I am using the repository pattern for ORM.
My question is about the proper way to handle persistent objects when I do not need them to be persistent.
Is detaching them good practice?
For example in one situation I might query the UserRepository and then query the BlahBlahBlahRepository, and then do some calculations on the objects and return a result.
However, I do not need those objects to persist and be monitored because they will not be changed. Do I need to be concerned about the overhead or is there something I can do besides calling detach on those objects.
How can I only load an actor if it has previously been formally created following domain rules? Everything I've seen using actorOf and persistence always creates an empty instance and then applies the [possibly empty] set of events that have occurred, whereas I would prefer to make empty instances unrepresentable. Is there a standard approach for requiring a "created" event and otherwise triggering failure via "not found"?
My thinking is to have one actor instance for each entity in the system, but my expectation is that less than 10% of the entities will be actively needed at any given time so I'm trying to avoid loading the entire set just to check validity when handling a request.
I'm new to Akka and event sourcing in general so if I'm thinking about things from an unhelpful perspective I'm open to any alternatives as well.
I guess you are talking about PersistentActors.
There is no api for pre persisting state outside of the PersistentActor. The idea is that actor keeps track of his state for himself. There is no profit of empty actors, actors should keep some state so when you initialise it via actorOf it should have kind of state Created. On the other hand you should not think it has saved its state until it reports to creator that it was persisted.
Persistent actors are loaded passively into the memory only when you initialise them explicitly, so all the entities won't be loaded at startup. If you want to passivate them you can stop the actors or invoke setReceiveTimeout method on actor's context.
I have a large Mutable Map object which occupies so much memory which all the children of the parent need to access or modify values to the same Map.
I am considering just passing the mutable map during child creation as constructor parameters to all the children upon which they can access or modify the map accordingly.
I just wanted to confirm that SCALA actually passes the object reference around and so the Mutable Map will not be copied all over again, instead all the children will be modifying the same Map instance?
This is a bad idea. The Akka team does not recommend shared mutable state of any kind.
The Akka way to solve your problem would be to make your map immutable and pass it to your children in immutable messages. If you are convinced that the map has to be mutable then have one actor manage the map and have the other actors send messages to it to retrive / update values. There is nothing wrong with mutable state within one actor.
I have a large Mutable Map object which occupies so much memory which
all the children of the parent need to access or modify values to the
same Map
This is exactly what Akka shines at compared to other concurrency mechanisms. Encapsulating mutable state inside an Actor and sending messages to the Actor to mutate the state is the correct and recommended approach.
So you need to pass an ActorRef to any actor who needs to modify the map. The cool thing is that other actor can be on a different JVM and it would still work.
This also takes care of your concern the large memory footprint of your Map.
I want to know how to check if Domain Object is in right state while saving it.
If Object has persistent information - it is clear as for instance I can check Order's amount in its Save method. However persistent ignorant objects don't have Save method. They just have data and behavior. Should I rely on developers' accuracy or I need to check all entities graphs somehow before saving it in database?
Perhaps I'm not understanding you right.
I'm not sure how you get an "ignorant" object. That seems to run against the core tenet of encapsulation. The only way to modify an object's state should be through its interface. It's the interface's responsibility to ensure any updates to state are valid. So, to your example, you shouldn't need to check the amount in the save() operation (assuming here "save" means persist). It should be updated as a consequence of e.g. calling addProduct() (or something similar - i.e. adding item to order updates amount).
Whether an object is persistent or transitory is irrelevant - it should always encapsulate state update through its interface.
Hope that helps - apologies if I've misunderstood.