recover() mechanism

[bandar]

hi martin, hi group

I'm new to this group,

there is something bugging me, I wonder how recover() mechanism works,  I take this actor from your example

class InvoiceProcessor(invoicesRef: Ref[Map[String, Invoice]]) extends Actor { this: Emitter =>
  // actor code
}

when recover() method called, is invoicesRef mutated ? or in other word can i replace invoicesRef with standard repository implementation rather than scala STM

thanks
bandirsen

[Martin Krasser]

Hi bandirsen,

Am 07.02.13 02:28, schrieb bandar:

hi martin, hi group

I'm new to this group,

there is something bugging me, I wonder how recover() mechanism works, 

the user guide explains in detail how recovery works. Please let me know if something is missing or unclear.

I take this actor from your example

class InvoiceProcessor(invoicesRef: Ref[Map[String, Invoice]]) extends Actor { this: Emitter =>
  // actor code
}

when recover() method called, is invoicesRef mutated ?

Yes. State referenced by invoicesRef is recovered from replayed event messages.

or in other word can i replace invoicesRef with standard repository implementation rather than scala STM.

In general, you shouldn't expose state by an actor and only access it via messages sent to (and received) that actor. Examples where it makes sense to expose actor state via STM references is explained here. In case of the example application, the InvoiceProcessor is the only writer to the STM reference, all other components only read from it, but can do so concurrently without blocking.

Cheers,
Martin

thanks
bandirsen --
You received this message because you are subscribed to the Google Groups "Eventsourced" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eventsourced...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

-- 
Martin Krasser

blog:    http://krasserm.blogspot.com
code:    http://github.com/krasserm
twitter: http://twitter.com/mrt1nz

[bandar]

Hi Martin,

Thanks for reply,

I came to conclusion that eventsourced main purpose is to ability to restore last actor state after application shutdown/crash using journaled messages, and has no relation with cqrs-eventsourcing architecture.

Since I, and maybe most of us here too, came to eventsourced when searching for cqrs-eventsourcing framework in scala, i think the InvoceProcessor example is a bit misleading newbies like me, for me its more "memory image pattern" implementation rather than cqrs-eventsourcing implementation, or maybe eventsourced is coupled tight with "memory image pattern" by design ?

I would like to see eventsourced library usage without memory image pattern, I believe eventsourced will be shine if used as "saga" in a cqrs-eventsourcing application but I need to dig it deeper.

Thanks
Bandirsen

[Martin Krasser]

Am 07.02.13 11:35, schrieb bandar:

Hi Martin,

Thanks for reply,

I came to conclusion that eventsourced main purpose is to ability to restore last actor state after application shutdown/crash using journaled messages,

Yes, that's one of its main purposes, another one is to support reliability of message exchanges (see this article for example). You may also be interested in how does Eventsourced persist actor state and how is this related to event sourcing.

and has no relation with cqrs-eventsourcing architecture.

No. See the reference application for an example how 'c'ommands and 'q'ueries can be separated. As an example, the StatisticsProcessor maintains a read model (the R in CQRS) that is updated from events emitted by the InvoiceProcessor. The InvoiceProcessor on the other hand processes commands and maintains a write model. Therefore, reads about update statistics and commands for changing invoice state are targeted at different models, a simple CQRS example.

Since I, and maybe most of us here too, came to eventsourced when searching for cqrs-eventsourcing framework in scala, i think the InvoceProcessor example is a bit misleading newbies like me, for me its more "memory image pattern" implementation rather than cqrs-eventsourcing implementation, or maybe eventsourced is coupled tight with "memory image pattern" by design ?

Yes, the key element to a memory image is using event sourcing. Furthermore, nothing prevents you to store read models in a database instead of in-memory (i.e. store the current state instead of changes/events). In this case, just make sure that the actor, that persists the read model, is not modified with the Eventsourced trait. Nevertheless, the key point to scalability (another important focus of Eventsourced) are append-only writes to an event log (journal), whereas update (in-place mutations in a database) may prevent scalability.

I would like to see eventsourced library usage without memory image pattern,

Actually, Eventsourced doesn't force actors to store their state in memory, they can also make updates to a database (in addition to write received event messages to an event log) or using a hybrid approach where only part of the application state is kept in memory e.g. the frequently used part of application state; other parts can be stored somewhere else and loaded on demand if needed. You have all the options with Eventsourced.

I believe eventsourced will be shine if used as "saga" in a cqrs-eventsourcing application but I need to dig it deeper.

There are examples of event sourced business processes (sagas) in the user guide like the order management example. It is also shown how to implement event sourced state machines which are a good basis for long-running, persistent business processes.

Cheers,
Martin