Multiple Data Object Brokers can be configured to address the same database. When implemented, one of these is designated the primary Data Object Broker, responsible for all access and updating of the database. Any other Data Object Broker that addresses this database is designated to be a secondary Data Object Broker and will be mostly idle until either the primary Data Object Broker fails, or an operator switches control to it. This mode of operating exploits the facilities of the IBM Coupling Facility and z/OS XCF communications.
In addition, a new TIBCO Object Service Broker address space called the Message Switch (MSW) helps to maintain access to the database by other TIBCO Object Service Broker components (such as Execution Environments and database servers) in the event of a switch of the primary Data Object Broker.
Figure 1 shows a sample implementation.
When running multiple Data Object Brokers, access to any Data Object Broker is only permitted via a MSW address space, and this access by MSW address spaces is only permitted using either the cross memory or XCF communication protocols. MSW address spaces do not support VTAM as a communication protocol.
In multiple Data Object Broker mode, it is the MSW address spaces that use what is currently the COMMID of a Data Object Broker in single mode. The Data Object Brokers automatically switch their communication port ID to be their XCF member name. As with a single Data Object Broker, the COMMID value for multiple Data Object Brokers must be specified for outgoing PEER-PEER connections.
When the primary Data Object Broker fails, all secondary Data Object Brokers and MSWs are notified by XCF. The MSWs terminate their sessions with other TIBCO Object Service Broker components and wait for the new primary Data Object Broker to complete initialization. Any connect requests from other TIBCO Object Service Broker components after this time will be held in the MSW address space until the primary Data Object Broker becomes available.
The first secondary Data Object Broker to obtain the system wide enqueue resource will become the new primary Data Object Broker, and will perform a standard TIBCO Object Service Broker restart, since there is no data available in the coupling facility. Once the new primary Data Object Broker becomes available, all MSW address spaces will process queued connection requests and processing will proceed as normal. User sessions will be able to reconnect to the primary Data Object Broker.
In addition, CICS Execution Environments, Native Execution Environments, and all z/OS gateways will automatically restart if the primary Data Object Broker fails. Only the active end-user sessions will not be reinstated. The above processing is intended to greatly reduce the outage time resulting from a Data Object Broker failure.