Precise Recovery with JMS

20-16 Oracle Complex Event Processing Developers Guide

20.3.2.7 Source Event Identity Externally

Many high availability solutions require that events be correlated between different servers and to do this events need to be universally identifiable. The best way to do this is use external information – preferably a timestamp – to seed the event, rather than relying on the Oracle CEP system to provide this. For more information, see Section 20.3.3.6, Prefer Application Time .

20.3.2.8 Understand the Importance of Event Ordering

For Oracle CEP high availability quality of service options that use queue trimming, not only must primary and secondary servers generate the same output events, but they must also generate them in exactly the same order. Primary and secondary servers must generate the same output events and in exactly the same order when you choose Oracle CEP high availability quality of service options that use queue trimming and equality-based event identify that is, nonmonotonic event identifiers - event identifiers that do not increase continually. In this case, generating output events in different orders can lead to either missed output events or unnecessary duplicate output events when there is a failure Consider the output event streams shown in Figure 20–8 . The primary has output events a, b, and c. After outputting event c, the primary sends the secondary a queue trimming message. Figure 20–8 Event Order The secondary trims all events in its queue generated prior to event c including event c itself. In this case, the set of events trimmed will be {a, b, e, d, c} which is wrong because the primary has not yet output events d and e. If a failover occurs after processing the trimming message for event c, events will be lost. To manage event ordering, consider the following design patterns: ■ Section 20.3.2.8.1, Prefer Deterministic Behavior ■ Section 20.3.2.8.2, Avoid Multithreading ■ Section 20.3.2.8.3, Prefer Monotonic Event Identifiers

20.3.2.8.1 Prefer Deterministic Behavior In order for an application to generate events in

the same order when run on multiple instances, it must be deterministic. The application must not rely on things like: ■ Random number generator that may return different results on different machines. ■ Methods like System.getTimeMillis or System.nanoTime which can return different results on different machines because the system clocks are not synchronized.

20.3.2.8.2 Avoid Multithreading Because thread scheduling algorithms are very timing

dependent, multithreading can be a source of nondeterministic behavior in applications. That is, different threads can be scheduled at different times on different machines. Understanding High Availability 20-17 For example, avoid creating an EPN in which multiple threads send events to an Oracle CEP high availability adapter in parallel. If such a channel is an event source for an Oracle CEP high availability adapter, it would cause events to be sent to the adapter in parallel by different threads and could make the event order nondeterministic. For more information on channel configuration to avoid, see: ■ Section 22.2.1, EventPartitioner ■ max-threads in Table C–9, Attributes of the wlevs:channel Application Assembly Element

20.3.2.8.3 Prefer Monotonic Event Identifiers Event identifiers may be monotonic or

nonmontonic. A monotonic identifier is one that increases continually such as a time value. A nonmonotonic identifier does not increase continually and may contain duplicates. In general, you should design your Oracle CEP application using monotonic event identifiers. Using a monotonic event identifier, the Oracle CEP high availability adapter can handle an application that may produce events out of order.

20.3.2.9 Write Oracle CQL Queries with High Availability in Mind

Not all Oracle CQL query usage is supported when using Oracle CEP high availability. You may need to redefine your Oracle CQL queries to address these restrictions. For more information, see Section 20.3.3, Oracle CQL Query Restrictions .

20.3.2.10 Avoid Coupling Servers

The most performant high availability for Oracle CEP systems is when servers can run without requiring coordination between them. Generally this can be achieved if there is no shared state and the downstream system can tolerate duplicates. Increasing levels of high availability are targeted at increasing the fidelity of the stream of events that the downstream system sees, but this increasing fidelity comes with a performance penalty.

20.3.2.11 Plan for Server Recovery

When a secondary server rejoins the multi-server domain, the server must have time to rebuild the Oracle CEP application state to match that of the current primary and active secondaries as Section 20.3.2.5, Choose an Adequate warm-up-window Time describes. The time it takes for a secondary server to become available as an active secondary after rejoining the multi-server domain will be a factor in the number of active secondaries you require. If a secondary is declared to be the new primary before it is ready, the secondary will throw an exception.

20.3.3 Oracle CQL Query Restrictions

When writing Oracle CQL queries in an Oracle CEP application that uses Oracle CEP high availability options, observe the following restrictions: ■ Section 20.3.3.1, Range-Based Windows ■ Section 20.3.3.2, Tuple-Based Windows