Broadcast Output Adapter High Availability Components

Understanding High Availability 20-11 During failover, the new primary enters the BECOMING_PRIMARY state and will not transition into the PRIMARY state until its event queue that it was accumulating as a secondary has been flushed. During this transition, new input events are buffered and some duplicate events may be output. When an Oracle CEP server rejoins the multi-server domain, if your application is an Oracle CEP high availability Type 1 application an application that must generate exactly the same sequence of output events as existing secondaries, it must wait the warm-up-window-length time you configure for the Oracle CEP high availability output adapter before it is available as a secondary. To implement this high availability quality of service, you configure your EPN with a high availability input adapter after each input adapter and a high availability broadcast output adapter before each output adapter. For more information, see Section 21.1.3, How to Configure Light-Weight Queue Trimming .

20.2.4 Precise Recovery with JMS

This high availability quality of service is characterized by a high performance overhead slower recovery time and maximum data integrity no missed events and no duplicate events during failover. This high availability quality of service is compatible with only JMS input and output adapters. In this high availability quality of service, we are not concerned with transactional guarantees along the event path for a single-server but in guaranteeing a single output from a set of servers. To achieve this, secondary servers listen, over JMS, to the event stream being published by the primary. As Figure 20–7 shows, this incoming event stream is essentially a source of reliable queue-trimming messages that the secondaries use to trim their output queues. If JMS is configured for reliable delivery we can be sure that the stream of events seen by the secondary is precisely the stream of events output by the primary and thus failover will allow the new primary to output precisely those events not delivered by the old primary. Figure 20–7 Precise Recovery with JMS During failover, the new primary enters the BECOMING_PRIMARY state and will not transition into the PRIMARY state its event queue that it was accumulating as a secondary has been flushed. During this transition, new input events are buffered and no duplicate events are output. 20-12 Oracle Complex Event Processing Developers Guide When an Oracle CEP server rejoins the multi-server domain, if your application is an Oracle CEP high availability Type 1 application the application must generate exactly the same sequence of output events as existing secondaries, it must wait the warm-up-window-length time you configure for the Oracle CEP high availability output adapter before it is available as a secondary. To implement this high availability quality of service, you configure your EPN with a high availability input adapter after each input adapter and a high availability correlating output adapter before each output adapter. To increase scalability, you can also use the cluster groups bean with high availability quality of service. For more information, see: ■ Section 21.1.4, How to Configure Precise Recovery With JMS ■ Section 23.2, Configuring Scalability With the ActiveActiveGroupBean

20.3 Designing an Oracle CEP Application for High Availability

Although you can implement Oracle CEP high availability declaratively, to fully benefit from the high availability quality of service you choose, you must design your Oracle CEP application to take advantage of the high availability options that Oracle CEP provides. When designing your Oracle CEP application for high availability, consider the following : ■ Section 20.3.1, Primary Oracle CEP High Availability Use Case ■ Section 20.3.2, High Availability Design Patterns ■ Section 20.3.3, Oracle CQL Query Restrictions

20.3.1 Primary Oracle CEP High Availability Use Case

You can adapt Oracle CEP high availability options to various Oracle CEP application designs but in general, Oracle CEP high availability is designed for the following use case: ■ An application receives input events from one or more external systems. ■ The external systems are publish-subscribe style systems that allow multiple instances of the application to connect simultaneously and receive the same stream of messages. ■ The application does not update any external systems in a way that would cause conflicts should multiple copies of the application run concurrently. ■ The application sends output events to an external downstream system. Multiple instances of the application can connect to the downstream system simultaneously, although only one instance of the application is allowed to send messages at any one time. Within these constraints, the following different cases are of interest: ■ The application is allowed to skip sending some output events to the downstream system when there is a failure. Duplicates are also allowed. For this case, the following Oracle CEP high availability quality of service options are applicable: