1. Transaction Manager for Microservices Developer Guide
  2. Manage the Transaction Coordinator
  3. About Session Affinity

11.1 About Session Affinity

When you enable session affinity, all the requests for a unique transaction or session are routed to the same endpoint or replica of the participant service that served the first request.

Use a sticky session to associate a service instance, a Kubernetes pod or a replica, with an application based on the oracle-tmm-txn-id HTTP header. A consistent hash is created based on the oracle-tmm-txn-id HTTP header, and then the sticky session is established. The MicroTx library and transaction coordinator include the oracle-tmm-txn-id HTTP header in all subsequent calls.

When the transaction initiator service calls the participant service, the MicroTx library injects the oracle-tmm-txn-id HTTP header in the outgoing request. All subsequent calls from MicroTx to the participant service also include this header. In this manner all requests are routed to the concerned replica of the transaction participant service.

Based on your business use case, you will need to enable session affinity for a participant service or for the transaction coordinator. When there are multiple replicas of a participant service, the request may be directed to different replicas in a single transaction. When you enable session affinity for a participant service, all the requests for a particular transaction or session are routed to the same endpoint or replica of the participant service that served the first request.

If you enable session affinity when it isn't required, it may have an adverse impact on the application's performance.

When should you enable session affinity for an XA participant service

Enable session affinity for an XA participant service in the following scenarios only if there are multiple instances or replicas of the participant service, so that all requests are routed to the concerned replica. You must enable session affinity or sticky sessions for an XA participant service in the following scenarios.

  • When a transaction participant uses a non-XA resource and the Logging Last Resource (LLR) or Last Record Commit (LRC) optimization is enabled.
  • When a transaction participant uses PostgreSQL as a resource manager, that requires you to use the same session for initiating the XA transaction and for all subsequent requests.

When should you enable session affinity for a Saga participant service

Enable session affinity for a Saga participant service if there are multiple instances or replicas of the participant service, so that all requests are routed to the concerned replica.

When should you enable session affinity for transaction coordinator

You don't need to enable session affinity for TCC transactions. For Saga and XA transactions, you must enable session affinity for the transaction coordinator in the following scenarios:

  • When you use internal memory as data store and deploy the transaction coordinator on more than one replica. This ensures that all requests are routed to the concerned replica of the transaction coordinator.
  • When you enable caching.

For information about enabling session affinity for a participant service or transaction coordinator, see Enable Session Affinity.

For each participant service, you may run one or more replicas of the service. The session affinity to a particular host is lost when you add or remove replicas for a participant service. For more details, see https://istio.io/latest/docs/reference/config/networking/destination-rule/#LoadBalancerSettings-ConsistentHashLB.

  • Enable Session Affinity
    When you enable session affinity, all the requests for a unique transaction or session are routed to the same endpoint or replica of the participant service that served the first request.

Parent topic: Manage the Transaction Coordinator