Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Event sourcing provides a flexible way to manage and persist grain state. An event-sourced grain has many potential advantages over a standard grain. For one, you can use it with many different storage provider configurations, and it supports geo-replication across multiple clusters. Moreover, it cleanly separates the grain class from definitions of the grain state (represented by a grain state object) and grain updates (represented by event objects).
The documentation is structured as follows:
JournaledGrain basics explains how to define event-sourced grains by deriving from JournaledGrain<TGrainState,TEventBase>, how to access the current state, and how to raise events that update the state.
Replicated instances explains how the event-sourcing mechanism handles replicated grain instances and ensures consistency. It discusses the possibility of racing events and conflicts, and how to address them.
Immediate/Delayed confirmation explains how delayed confirmation of events and reentrancy can improve availability and throughput.
Notifications explains how to subscribe to notifications, allowing grains to react to new events.
Event sourcing configuration explains how to configure projects, clusters, and log-consistency providers.
Built-in log-consistency providers explains how the three currently included log-consistency providers work.
JournaledGrain diagnostics explains how to monitor for connection errors and get simple statistics.
The behavior documented above is reasonably stable regarding the JournaledGrain
API. However, we expect to extend or change the list of log consistency providers soon to more easily allow you to plug in standard event storage systems.