SYSTEM AND METHOD FOR ADAPTIVELY INTEGRATING A DATABASE STATE NOTIFICATION SERVICE WITH A DISTRIBUTED TRANSACTIONAL MIDDLEWARE MACHINE

• US 20150324222A1
• Filed: 01/22/2015
• Published: 11/12/2015
• Est. Priority Date: 05/06/2014
• Status: Active Grant

• Current Assignee: Oracle International Corporation (Oracle Corporation)
• Original Assignee: Oracle International Corporation (Oracle Corporation)
• Inventors: LITTLE, TODD J., ZHENG, QINGSHENG, SHEN, XUGANG
• Granted Patent: US 9,569,224 B2
• Time in Patent Office: Days
• US Class Current: 1/1
• CPC Class Codes: G06F 16/27 Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
• CPC Class Codes: G06F 9/44 Arrangements for executing specific programs
• CPC Class Codes: G06F 9/466 Transaction processing
• CPC Class Codes: H04L 65/40 Support for services or applications
• CPC Class Codes: H04L 67/1097 for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]

Abstract

A system and method can handle various database state notifications in a transactional middleware machine environment. The system can connect one or more transaction servers to a database service, wherein the database service is associated with a notification service. Furthermore, a notification service client that is associated with said one or more transaction servers can receive one or more events from the notification service, wherein said one or more events indicates one or more state changes in the database service. Then, one or more transaction servers operate to adaptively respond to the one or more state changes in the database service.

Claims

1. A method for handling various database state notifications in a transactional middleware machine environment, comprising:

connecting one or more transaction servers to a database service, wherein the database service is associated with a notification service;

receiving, via a notification service client that is associated with said one or more transaction servers, one or more events from the notification service, wherein said one or more events indicate one or more state changes in the database service; and

adaptively responding, via said one or more transaction servers, to the one or more state changes in the database service.

2. The method of claim 1, further comprising:

allowing the database service to be based on a clustered database that includes one or more databases, instances, host nodes, and services.

3. The method of claim 1, further comprising:

handling the one or more events based on one or more routing policies.

4. The method of claim 1, further comprising:

storing, via the notification service client, information on the one or more state changes in the database service in a shared memory, and

allowing another transaction server to obtain the information on the one or more state changes in the database service.

5. The method of claim 1, further comprising:

allowing said one or more events to be high availability (HA) events, each of which indicates an up/down for at least one of a service, an instance, or a host node associated with the database service.

6. The method of claim 5, further comprising:

supporting fast connection failover based on the HA events, wherein said one or more transaction servers operate to at least one of

provide rapid failure detection,

remove one or more invalid database connections and create one or more invalid database connections,

perform shutdown for planned and/or unplanned database node outages, and

adapt to topological changes associated with the database service.

7. The method of claim 1, further comprising:

allowing said one or more events to be runtime load balance (RLB) events, each of which indicates a runtime load and affinity per database instance that is associated with the database service.

8. The method of claim 7, further comprising:

distributing runtime work requests to active database instances based on the RLB events.

9. The method of claim 1, further comprising:

allowing the notification service client to be a transactional server.

10. The method of claim 1, further comprising:

creating, via a main process of the transactional server, one or more receiving threads, each of which operates to receive and handle one or more events.

11. A system for handling various database state notifications in a transactional middleware machine environment, comprising:

one or more microprocessors;

one or more transaction servers, running on the one or more microprocessors, wherein the one or more transaction servers is connected to a database service, wherein the database service is associated with a notification service; and

a notification service client that is associated with said one or more transaction servers, wherein said notification service client operates to receive one or more events from the notification service, wherein said one or more events indicate one or more state changes in the database service, and

wherein said one or more transaction servers operate to adaptively respond to the one or more state changes in the database service.

12. The system according to claim 11, wherein:

the database service is based on a clustered database that includes one or more databases, instances, host nodes, and services.

13. The system of claim 11, wherein:

the notification service client operates to handle the one or more events based on one or more routing policies.

14. The system of claim 11, wherein:

the notification service client operates to

store information on the one or more state changes in the database service in a shared memory, and

allow another transaction server to obtain the information on the one or more state changes in the database service.

15. The system of claim 11, wherein:

said one or more events are high availability (HA) events, each of which indicates an up/down for at least one of a database service, a database instance, or a host node associated with the database service.

16. The system of claim 15, wherein:

said one or more transaction servers operates to at least one of

provide rapid failure detection,

remove one or more invalid database connections and create one or more invalid database connections,

perform shutdown for planned and/or unplanned database node outages, and

adapt to topological changes associated with the database service.

17. The system of claim 11, wherein:

said one or more events are runtime load balance (RLB) events, each of which indicates a runtime load and affinity per database instance that is associated with the database service.

18. The system of claim 17, wherein:

said one or more transaction servers operates to distribute runtime work requests to active database instances based on the RLB events.

19. The system of claim 11, wherein:

the notification service client is a transactional server, wherein a main process of the transactional server operates to create one or more receiving threads, each of which operates to receive and handle one or more events.

20. A non-transitory machine readable storage medium having instructions stored thereon that when executed cause a system to perform the steps comprising:

connecting one or more transaction servers to a database service, wherein the database service is associated with a notification service;

receiving, via a notification service client that is associated with said one or more transaction servers, one or more events from the notification service, wherein said one or more events indicates one or more state changes in the database service; and

adaptively responding, via said one or more transaction servers, to the one or more state changes in the database service.