PersistentActor maintenance and growth.

[Robert Budźko]

Hi,

Recently, I've been playing with persistent actors a little bit. I've decided to design my PoC in such a way that some actors are distributed entities (state holders). Usually, not persistent actor supervises a group of entity-actors (of the same type) and asks them to handle commands (usually changing the state). I was delighted with this approach in the first place, but now I doubt my design, because I've encountered problem of migration when persistent actor is being developed/refactored, so both commands and events are changed. Additionally, I'm a little bit unhappy because of  serialization in form of "blob".

I got couple of ideas how to solve my problem but non of them is convincing me 100%:

1) Prepare custom serializer which is able to serialize my events into for example relational model, so I can migrate database when implementation of event is changed (benefit). In this case, I don't like the fact that I have to add serialization implementation for each new agent.

2) I was thinking about recognition of event version in serializer and having all versions of events in classpath, so it will sustain backward compatibility. I'm not even sure if it is possible (have not confirmed it yet). I'm also afraid that code might become nasty after couple of versions.

3) I wonder if it is possible to somehow snapshot state into latest version so, after next start of node, old versions of events are not required any more.

Problems I'm trying to solve are:

1) Possibility of migration of persisted state. (ie. executing sql in relational database)

2) Possibility of accessing state w/o deserialization into event class. (ie. peeking into relational database).

Do you know any patterns, approaches which could lead to solution of those problems? Maybe my design is not valid in the end :-] .

Thank you,

Robert

PS Relational database was used as an example of different storage then default one. It can by any different storage.

[Soumya Simanta]

I'm not an expert and still learning how to design systems using this approach. 

Here are some suggestions: 

1. If you design your domain using DDD properly you will end up with a reasonable set of aggregates, entities and value objects. You should design your events to mirror your business processes. I personally feel DDD requires more investment and skills but if you get it right you can avoid a lot of complexity afterwards. 

2. Even if your core events don't change you may need to add information later which effectively changes your event resulting in a new version. Something like this is likely to happen at initial stages of your project when the business concepts are are still in flux. One way to address this is to replay the old events from start and create a new set of events with the new version. 

I would also be very interested to hear what others have to say on this.

-Soumya

[Robert Budźko]

On Sunday, January 11, 2015 at 9:10:21 PM UTC+1, Soumya Simanta wrote:

2. Even if your core events don't change you may need to add information later which effectively changes your event resulting in a new version. Something like this is likely to happen at initial stages of your project when the business concepts are are still in flux. One way to address this is to replay the old events from start and create a new set of events with the new version. 

Sounds like a plan. I was wondering about this approach and it forces us to have both (old and new) versions of events in class path. I might be wrong, but it seems like quite error prone process (remembering about removing unused versions for next release, but keeping n-1 so it can be replied etc.).

Additionally, I'm also interested in "non blob" serialization, because I cant recall serializing non-binary information into blob and not regretting it soon enough :-] .

Robert

[Akka Team]

Hi Robert,

You could implement a journal which serializes differently, it's up to the journal implementation really. 

The Journals are given the payload: Any and are free to serialize how they see fit.

For optimal performance binary encoding is the obvious choice, and also for schema evolution many binary formats have things in their impls ready for it,

please refer to this discussion for more information where we discussed many formats in depth: akka-user: Best practices using Akka Persistence with long-running projects?.

Also, the above linked thread should help you figuring out how you want to keep old versions of events (there's 3 ways basically: evolve the schema non-breakingly, 

"promote" during old schema event replay to new schema event, versioning and multiple event types).

The choice on how to deal with this goes hand in hand with which serialisation format you are going to pick (and non-binary doesn't really solve these problems magically - the same problems remain, except it's easier to look at them).

Hope this helps, cheers!

--
>>>>>>>>>> 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+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

--

Akka Team

Typesafe - The software stack for applications that scale

Blog: letitcrash.com
Twitter: @akkateam

[Robert Budźko]

Hi,

Thanks for your explanations. I've also found link you provided (long running projects one) and looks like promotion is what suits me the most in this particular case. I can also combine it with journal implementation (which I somehow missed during my learning process). Being able to inject own implementation of journal makes the whole picture more colorful!

Thanks for all those great advice,

Robert

You received this message because you are subscribed to a topic in the Google Groups "Akka User List" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/akka-user/tDODu1E2SF8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to akka-user+...@googlegroups.com.