Transaction Sticky Load Balance Policy for Server Clusters

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Existing load balance policies in application servers fail to ensure that all operations within a transaction are executed by the same server node, leading to issues with ACID properties and transaction integrity, especially when remote clients invoke methods on different server nodes, and failover mechanisms are inadequate.

Innovation Solution

Implementing a transaction sticky load balance policy where each server node and client receives a load balance policy that directs all invocations within a transaction to the same target server node, ensuring that all business methods are executed on this node, and providing a proxy to manage failovers and maintain transaction integrity.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If conventional round-robin load balance policy is used, then load is distributed across multiple server nodes, but transaction integrity and ACID properties cannot be guaranteed

Engineering Contradiction:

Improveload distributionVSAvoidtransaction integrity

Core Design Contradiction:

ProductivityVSReliability

Solution Approach 1:

The system performs preliminary actions by establishing transaction affinity rules before transaction execution. The load balancer pre-configures sticky session policies and transaction routing rules that ensure all operations within a transaction are directed to the same server node, preventing transaction integrity issues before they occur.

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The invention introduces an intermediary component (transaction coordinator or enhanced load balancer) that mediates between the client and server nodes. This intermediary maintains transaction state information and directs all transaction operations to the appropriate server node, ensuring ACID properties while still allowing load distribution across multiple nodes for different transactions.

Inventive Principle:

Principle #24Intermediary (Mediator)

2Productivity

If multiple server nodes are used for different EJB invocations, then system capacity is increased, but rollback operations fail when transactions span multiple nodes

Engineering Contradiction:

Improvesystem capacityVSAvoidtransaction rollback

Core Design Contradiction:

ProductivityVSEase of operation

Solution Approach 1:

The invention merges transaction state management across server nodes by implementing a distributed transaction coordinator that consolidates transaction information. When a transaction spans multiple nodes, the coordinator combines the state from all involved nodes, enabling centralized rollback control that works seamlessly across the distributed system while maintaining high system capacity.

Inventive Principle:

Principle #5Merging (Combining)

Solution Approach 2:

The system implements feedback mechanisms where server nodes report transaction state and operation results back to the transaction coordinator. This feedback loop enables the coordinator to track which nodes are involved in each transaction, allowing proper rollback propagation to all relevant nodes while maintaining the ability to utilize multiple nodes for increased system capacity.

Inventive Principle:

Principle #23Feedback

3Use of energy by moving object

If load balance policy distributes transactions across nodes, then resource utilization is improved, but failover mechanisms become inadequate when nodes fail

Engineering Contradiction:

Improveresource utilizationVSAvoidfailover capability

Core Design Contradiction:

Use of energy by moving objectVSReliability

Solution Approach 1:

The system implements beforehand cushioning by pre-establishing backup server node assignments and transaction affinity rules. When a primary server node fails, the load balancer can quickly redirect transactions to pre-designated backup nodes without losing transaction integrity. This cushioning mechanism ensures high resource utilization during normal operation while maintaining robust failover capability.

Inventive Principle:

Principle #11Beforehand cushioning (Prior cushioning)

Solution Approach 2:

The invention introduces dynamic transaction affinity management where server-node assignments are not fixed but can adapt in real-time. The load balancer dynamically adjusts transaction routing based on current server node availability and health status, allowing the system to maintain high resource utilization when nodes are healthy while automatically failing over to alternative nodes when failures occur.

Inventive Principle:

Principle #15Dynamics

Data Source

PatentUS9600341B2Transaction sticky load balance policies

Publication Date: 2017.03.21 RED HAT INC

AI summary

A transaction sticky load balance policy allows a remote client to choose a target server node from a server cluster to provide a transaction service. The load balance policy directs invocations of business methods within a transaction to the same target server node. The remote client receives the load balance policy from a proxy, which is downloaded to the remote client from one of the server nodes in the server cluster. The remote client selects a target server node according to the load balance policy. The remote client then invokes the business methods within a transaction on the target server node via the proxy. The target server node can execute all of the business methods within the transaction on a Java virtual machine. The business methods can be implemented with Enterprise JavaBeans (EJBs).