| div | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||
|
Overview
| Excerpt |
|---|
Of Talon's two High Availability models, Event Sourcing requires more discipline to use but can yield better performance particularly for latency sensitive applications. In event sourcing |
...
, rather than replicating changes to state object and outbound messages, an application's inbound messages are replicated and replayed to produce the same application state and outbound messages. This section discusses the anatomy of an application coded for Event Sourcing. |
Event Sourcing has several performance advantages that are of particular interest to applications concerns with very low latency. With event sourcing, replication is much cheaper because:
- Received messages don't require re-serialization before replication (they are received in serialized form)
- Received messages can be replicated in parallel with the execution of business logic which can effectively reduce the storage cost overhead to 0.zero!
While the premise behind Event Sourcing is simple, it requires discipline on the part of the application developer to ensure that no business logic decisions are made based on any data but that in the inbound messages and the state generated by those message to date, otherwise it would lead to divergent state on the primary and backup members. For example, something as simple as making a logical decision based on System.currentTimeMillis() could lead to the primary instance accepting an order and a backup instance rejecting an order as stale because of clock skew. In the event that the primary instance fails, the order would then not exist on the backup.
...
Register Messaging Factories
When working with state replication both the ADM and message and state object event sourcing only message factories need to be registered with the runtime. Registering the state factory allows the underlying state replication machinery to deserialize replicated state objects based on the ids encoded in the replication stream. The message factories are used for deserializing replicated outbound the application's inbound messages as well as messages received from message buses. The state , and also when replaying them from the application's transaction log or during receipt by a backup instance when the inbound messaging stream is replicated from the primary instance. The message factories can be declared in your config.xml or programmatically:
...