Contact sessions always start on a content delivery cluster, and the contact remains connected to the same server cluster until the session ends. The cluster name is recorded in the xDB and is visible to all other agents. This ensures that a contact record is not loaded into two clusters at the same time.
Most sessions are not transferred to other clusters and always use a global hostname (for example www.company.com) to access the website. No redirection occurs for sessions operating on the global hostname when contact sessions are available without lock conflicts.
When a contact is connected to one cluster and makes an attempt from another cluster to start a new session with another device, the system transfers the new device session to the cluster where the contact originated.
Transferring contact sessions
Reasons for transferring contact sessions:
- At the start of a device session, when the contact connected to the device has an active contact session on another cluster.
- During a device session, when a previously unidentified contact is identified as an existing, known contact and who has an active contact session on another cluster.
How contacts sessions are transferred:
- A server-to-server request is triggered to transfer the session payload to the target content delivery cluster.
- A user agent (browser) is redirected onto a service URL on the target cluster that connects it to the newly created session
- A user agent (browser) is redirected to the application URL on the target cluster equal to the application URL on the originating cluster.
The following diagram shows the process of transferring contact sessions from one cluster to another. Device 1 is the first device that the contact uses to connect to the website. This session is still active when the same contact begins a second parallel visit using Device 2.