The Talon Manual

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Fixing some typos.

...

Code Block
languagejava
@AppHAPolicy(value=AepEngine.HAPolicy.StateReplication)
public class Application {
 ...
}

Provide a StateFactory

An AEPEngine AepEngine is application state agnostic: it deals with your application an 's state as a collection of plain old java object graph 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 anotated 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. 

...

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 graph tree (made up of the fields and collections it holds. Changes made to objects referenced by the root or it's its children are tracked by the platform and replicated or persisted transparently.

...

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

...

To actually achieve high availability storage must be configured for the application. The primary means of storage is for Talon apps is through clustered replication to a backup instance. Talon also logs state changes to a disk-based transaction log as a fallback mechanism. Storage and persistence can be enabled in the application's configuration xmlXML

Code Block
<app name="processor" mainClass="com.sample.Application">
  ...
  <storage enabled="true">
    ....
    <clustering enabled="true"/>
    <persistence enabled="true">
      <!-- 
        When using Xbuf encoded entities,
        detached persist is not supported.
        -->
      <detachedPersist enabled="false"/>
    </persistence>
 </storage>
</app>

...

Enabling persistence causes the replication stream that is sent to backup instances to also be logged locally on disk to a transaction log file. The transaction log file can be used to recover application state from a cold start , and is also used to initialize new cluster members that connect to it so when clustering is enabled, persistence must be enabled as well. 

...

See State Tree Limitations for a discussion of current state graph tree limitations.