The Talon Manual

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Excerpt

State Replication is the simpler of Talon's 2 two High Availability models. With State Replication, Talon replicates changes to state and the outbound messages emitted by your application's message handlers. In the event of a failover to a backup or a cold start recovery from a transaction log your application's state is available at the same point where processing left off, and the engine will retransmit any outbound messages that were left in doubt as a result of the failure. This sections discusses

 This section discusses the anatomy of an application using State Replication.

Coding For State Replication

...

  • Modeling Messages and State
  • Declaring a main class annotated for with HAPolicy of StateReplication
  • Providing Talon with a state factory for creating your application state
  • Writing message handlers to perform business logic. 

...

An AepEngine is application state agnostic: it deals with your application's state as a collection of plain old java objects organized into a state tree with a single object root. Given the root object for your application's state, the underlying store will track changes made to fields on the root (and its descendants) and replicate or persist those changes. As such, an AepEngine needs to be able to create a new application state during when your application is initialized. This is done by finding a method on your main application class annotated with @AppStateFactoryAccessor. The state factory accessor returns a newly initialized set of state for the engine to manage. As messages are processed the engine will pass the relevant state root back into the application to be operated upon. 

 

Code Block
languagejava
@AppStateFactoryAccessor
final public IAepApplicationStateFactory getStateFactory() {
    return new IAepApplicationStateFactory() {
        @Override
        final public Repository createState(MessageView view) {
            return Repository.create();
        }
    };
}

As your application makes changes to this root object (setting fields etc), the engine will monitor the root and replicate deltas to backup members or disk. 

Tip

Your application should only return one state object root. This platform will not call this method on every message, just the first time a message is received and the application state is created. In other words, your application will have a single object that represents its state. This object forms the root of your application's state object tree (made up of the fields and collections it holds. Changes made to objects referenced by the root or its children are tracked by the platform and replicated or persisted transparently.

 

 

Info

The state factory should return an empty, uninitialized object. The platform will invoke the state factory during application initialization with a null argument to determine the type of the application's root state, and will subsequently invoke the state factory on receipt of a MessageView when state has not already been created for the application. The application should not store a reference to the application state that it returns ... it is the job of the platform to manage the state tree once it has been created by either passing the state root into an EventHandler or returning it via a call to AepEngine.getApplicationState(final MessageView message)


Inject Message Sender

If your application will send messages, it can add an injection point for the underlying AepEngine to inject a message sender.

...