High Availability and Oracle Coherence

Understanding High Availability 20-13 – Section 20.2.1, Simple Failover ■ The application is allowed to send duplicate events to the downstream system, but must not skip any events when there is a failure. For this case, the following Oracle CEP high availability quality of service options are applicable: – Section 20.2.2, Simple Failover with Buffering – Section 20.2.3, Light-Weight Queue Trimming ■ The application must send exactly the same stream of messagesevents to the downstream system when there is a failure, modulo a brief pause during which events may not be sent when there is a failure. For this case, the following Oracle CEP high availability quality of service options are applicable – Section 20.2.4, Precise Recovery with JMS

20.3.2 High Availability Design Patterns

When designing your Oracle CEP application for use with Oracle CEP high availability options, observe the following design patterns: ■ Section 20.3.2.1, Select the Minimum High Availability Your Application can Tolerate ■ Section 20.3.2.2, Use Oracle CEP High Availability Components at All Ingress and Egress Points ■ Section 20.3.2.3, Only Preserve What You Need ■ Section 20.3.2.4, Limit Oracle CEP Application State ■ Section 20.3.2.5, Choose an Adequate warm-up-window Time ■ Section 20.3.2.6, Ensure Applications are Idempotent ■ Section 20.3.2.7, Source Event Identity Externally ■ Section 20.3.2.8, Understand the Importance of Event Ordering ■ Section 20.3.2.9, Write Oracle CQL Queries with High Availability in Mind ■ Section 20.3.2.10, Avoid Coupling Servers ■ Section 20.3.2.11, Plan for Server Recovery

20.3.2.1 Select the Minimum High Availability Your Application can Tolerate

Be sure that the extra cost of precise recovery per-node throughput decrease is actually necessary for your application.

20.3.2.2 Use Oracle CEP High Availability Components at All Ingress and Egress Points

You must use an Oracle CEP high availability input adapter after each regular input adapter and you must use an Oracle CEP high availability output adapter before each regular output adapter. 20-14 Oracle Complex Event Processing Developers Guide

20.3.2.3 Only Preserve What You Need

Most Oracle CEP systems are characterized by a large number of raw input events being queried to generate a smaller number of “enriched” events. In general it makes sense to only try and preserve these enriched events – both because there are fewer of them and because they are more valuable.

20.3.2.4 Limit Oracle CEP Application State

Oracle CEP systems allow you to query windows of events. It can be tempting to build systems using very large windows, but this increases the state that needs to be rebuilt when failure occurs. In general it is better to think of long-term state as something better kept in stable storage, such as a distributed cache or a database – since the high availability facilities of these technologies can be appropriately leveraged.

20.3.2.5 Choose an Adequate warm-up-window Time

When a new Oracle CEP server is added to an Oracle CEP high availability multi-server domain or an existing failed server restarts, the server will not have fully joined the Oracle CEP high availability deployment and notification groups until all applications deployed to it have fully joined. The type of application determines when it can be said to have fully joined. Oracle CEP high availability applications can be described as Type 1 or Type 2 applications as Table 20–2 shows. For more information, see Section 20.1.1.3, Rejoining the High Availability Multi-Server Domain .

20.3.2.5.1 Type 1 Applications A Type 1 application requires the new secondary to

generate exactly the same sequence of output events as existing secondaries once it fully joins the Oracle CEP high availability deployment and notification groups. It is a requirement that a Type 1 application be able to rebuild its internal state by processing its input streams for some finite period of time warm-up-window time, after which it generates exactly the same stream of output events as other secondaries running the application. The warm-up-window time is configured on an Oracle CEP high availability output adapter. The warm-up-window time length is specified in terms of seconds or minutes. For example, if the application contains Oracle CQL queries with range-based windows of 5, 7, and 15 minutes then the minimum warm-up-window time is 15 minutes the maximum range-based window size. Oracle recommends that the maximum window length be padded with a few minutes time, as well, to absolutely ensure that the necessary state is available. So, in the previous example 17 minutes or even 20 minutes would be a good length for the warm-up-window time. The Oracle CEP server uses system time during the warm-up-window time period, so it is not directly correlated with the application time associated with events being processed. Table 20–2 Oracle CEP High Availability Application Types Application Type Must generate exactly the same sequence of output events? Must be able to rebuild internal state by processing input streams within a finite period of time? Must wait this period of time before it has fully joined? Type 1 Yes Yes Yes Type 2 No No No