System and method for supporting transaction affinity based on resource manager (RM) instance awareness in a transactional environment

• US 9,977,694 B2
• Filed: 02/09/2017
• Issued: 05/22/2018
• Est. Priority Date: 04/28/2014
• Status: Active Grant

• Current Assignee: Oracle International Corporation (Oracle Corporation)
• Original Assignee: Oracle International Corporation (Oracle Corporation)
• Inventors: Shen, Xugang, Zhang, Qingsheng, Little, Todd J, Jin, Yongshun
• Primary Examiner(s): Chen, Qing
• Assistant Examiner(s): Lyons, Andrew M
• Application Number:
  US15/428,704
• Publication Number:
  US 20170153910A1
• Time in Patent Office: 467 Days
• Field of Search: 718101, 718104
• CPC Class Codes: G06F 9/466 Transaction processing
• CPC Class Codes: G06F 9/467 Transactional memory G06F9/528 takes precedence
• CPC Class Codes: G06F 9/5083 Techniques for rebalancing the load in a distributed system
• CPC Class Codes: H04L 67/10 in which an application is distributed across nodes in the network software deployment G06F8/60; multiprogramming arrangements G06F9/46

Abstract

A system and method can support transaction processing in a transactional environment. A transactional system operates to route a request to a transactional server, wherein the transactional server is connected to a resource manager (RM) instance. Furthermore, the transactional system can assign an affinity context to the transactional server, wherein the affinity context indicates the RM instance that the transactional server is associated with, and the transactional system can route one or more subsequent requests that are related to the request to the transactional server based on the affinity context.

Claims

1. A method for supporting transaction processing in a transactional system comprising a plurality of transactional servers, and a clustered database comprising a plurality of resource manager (RM) instances, the method comprising:

receiving a plurality of requests to the transactional system;

routing each of the plurality of requests to a transactional server of the plurality of transactional servers, wherein the transactional server is connected to an RM instance of the plurality of RM instances;

establishing for each of the plurality of requests an affinity context identifying a transactional server of the plurality of transactional servers, a database name, a database service name, and an RM instance name associated with transactions responsive to said each of the plurality of requests;

storing in a shared memory the affinity contexts for said each of the plurality of requests;

receiving a subsequent request to the transactional system; and

routing the subsequent request to a particular transactional server of the plurality of transactional servers using a transaction affinity routing policy which identifies a relationship between the subsequent transaction and the stored affinity contexts established for the plurality of requests, wherein said transaction affinity routing policy performs the additional steps of;

routing the subsequent request to the particular transactional server where the particular transactional server includes one of a same RM instance name, same database name, and same database service name as the subsequent request, and

routing the subsequent request to the particular transaction server according to a load balancing function if no particular server is identified based on said one or more of a same RM instance name, same database name, and same database service name as the subsequent request.

2. The method of claim 1, wherein said transaction affinity routing policy:

(a) routes the subsequent request to the particular transactional server associated with an affinity context which includes a same RM instance name, same database name, and same database service name as the subsequent request;

(b) if no particular server is identified in step (a) routes the subsequent request to the particular transaction server associated with an affinity context including a same database name and same database service name as the subsequent request;

(c) if no particular server is identified in steps (a) and (b) routes the subsequent request to the particular transaction server associated with an affinity context including a same database name and same RM instance name as the subsequent request;

(d) if no particular server is identified in steps (a), (b) and (c) routes the subsequent request to the particular transaction server associated with an affinity context including a same database name as the subsequent request; and

(e) if no particular server is identified in steps (a), (b), (c) and (d) routes the subsequent request to the particular transaction server using a load balancing function.

3. The method of claim 1, wherein the transaction affinity routing policy identifies a relationship between the subsequent transaction and the stored affinity contexts established for the plurality of requests based on a database name, an RM instance name, and a database service name.

4. The method of claim 1, further comprising:

allowing said plurality of requests and said subsequent request to be associated with a client context.

5. The method of claim 1, further comprising:

propagating the affinity contexts established for each of the plurality of requests in the transactional system using messages.

6. The method of claim 1, further comprising:

updating a transaction context for the subsequent request based on a message received from another transactional server comprising an affinity context established for a related one of the plurality of requests.

7. The method of claim 1, further comprising:

updating a transaction context for the subsequent request using an affinity context string to transfer the affinity context from a transactional domain to another transactional domain.

8. The method of claim 1, further comprising:

using a connector to transfer the affinity contexts from a transactional system to an application server.

9. A system for supporting processing a global transaction in a transactional middleware environment, comprising:

one or more microprocessors;

a transactional system comprising a plurality of transactional servers running on the one or more microprocessors, and a clustered database comprising a plurality of resource manager (RM) instances, wherein the transactional system operates to perform steps comprising;

receiving a plurality of requests to the transactional system;

routing each of the plurality of requests to a transactional server of the plurality of transactional servers, wherein the transactional server is connected to an RM instance of the plurality of RM instances;

establishing for each of the plurality of requests an affinity context identifying a transactional server of the plurality of transactional servers, a database name, a database service name, an RM instance name associated with transactions responsive to said each of the plurality of requests;

storing in a shared memory the affinity contexts for said each of the plurality of requests;

receiving a subsequent request to the transactional system; and

routing the subsequent request to a particular transactional server of the plurality of transactional servers using a transaction affinity routing policy which identifies a relationship between the subsequent transaction and the stored affinity contexts established for the plurality of requests, wherein said transaction affinity routing policy performs the additional steps of;

routing the subsequent request to the particular transactional server where the particular transactional server includes one of a same RM instance name, same database name, and same database service name as the subsequent request, and

routing the subsequent request to the particular transaction server according to a load balancing function if no particular server is identified based on said one or more of a same RM instance name, same database name, and same database service name as the subsequent request.

10. The system according to claim 9, wherein said transaction affinity routing policy:

(a) routes the subsequent request to the particular transactional server associated with an affinity context which includes a same RM instance name, same database name, and same database service name as the subsequent request;

(b) if no particular server is identified in step (a) routes the subsequent request to the particular transaction server associated with an affinity context including a same database name and same database service name as the subsequent request;

(c) if no particular server is identified in steps (a) and (b) routes the subsequent request to the particular transaction server associated with an affinity context including a same database name and same RM instance name as the subsequent request;

(d) if no particular server is identified in steps (a), (b) and (c) routes the subsequent request to the particular transaction server associated with an affinity context including a same database name as the subsequent request; and

(e) if no particular server is identified in steps (a), (b), (c) and (d) routes the subsequent request to the particular transaction server using a load balancing function.

11. The system according to claim 10,

wherein the transaction affinity routing policy is based on a database name, an RM instance name, and a database service name.

12. The system according to claim 9, wherein said plurality of requests and said subsequent request are associated with a client context.

13. The system according to claim 9, wherein the transactional system is configured to propagate the affinity contexts established for each of the plurality of requests in the transactional system using messages.

14. The system according to claim 9, wherein the transactional system is configured to update a transaction context for the subsequent request based on a message received from another transactional server comprising an affinity context established for a related one of the plurality of requests.

15. The system according to claim 9, wherein the transactional system is configured to use an affinity context string to transfer the affinity contexts from a transactional domain to another transactional domain.

16. A non-transitory machine readable storage medium having instructions stored thereon for supporting transaction processing in a transactional system comprising a plurality of transactional servers, and a clustered database comprising a plurality of resource manager (RM) instances, which instructions, when executed, cause the transactional servers in the transactional system to perform steps method comprising:

receiving a plurality of requests to the transactional system;

routing each of the plurality of requests to a transactional server of the plurality of transaction servers, wherein the transactional server is connected to an RM instance of the plurality of RM instances;

establishing for each of the plurality of requests an affinity context identifying a transactional server of the plurality of transactional servers, a database name, a database service name, an RM instance name associated with transactions responsive to said each of the plurality of requests;

storing in a shared memory the affinity contexts for said each of the plurality of requests;

receiving a subsequent request to the transactional system; and

routing the subsequent request to a particular transactional server of the plurality of transactional servers using a transaction affinity routing policy which identifies a relationship between the subsequent transaction and the stored affinity contexts established for the plurality of requests, wherein said transaction affinity routing policy performs the additional steps of;

routing the subsequent request to the particular transactional server where the particular transactional server includes one of a same RM instance name, same database name, and same database service name as the subsequent request, and

routing the subsequent request to the particular transaction server according to a load balancing function if no particular server is identified based on said one or more of a same RM instance name, same database name, and same database service name as the subsequent request.