Tomcat Server Unable To Access Shared HTTP Session In Web Applications Deployed Across Different Vendors' Application Server Products
(Doc ID 1553604.1)
Last updated on JULY 03, 2017
Applies to:Oracle Coherence - Version 184.108.40.206 and later
Information in this document applies to any platform.
An attempt is being made to try to share HTTP sessions between Weblogic and Tomcat servers using Coherence 3.7.1, similar to what is described in the Coherence*Web User's Guide in section 2.4. However, the architecture is atypical, with the HTTP sessions always been created by an application running on the WebLogic Servers and then flowing to an application running on the Tomcat servers. Once the end-user's requests have migrated to the Tomcat servers they never move back to the WebLogic Servers.
Unfortunately, after following the directions in the documentation the Tomcat server is always creating a new session instead of using the session created from accessing Weblogic first.
Below are the sample configurations used in Weblogic and Tomcat applications. Copies of these files can be found attached to this article.
The web.xml from Weblogic application:
From which it can be concluded that there is a problem with the processing and removal of the session affinity token and the JVMID.
That is, the Coherence*Web functionality in the Tomcat application is treating the complete HTTP Session ID value, BBYSAuM0g4OlkKnBeowSdWSgYRfOxMTMASY8PPTXXIsDWwA6BpXT!563360309 as the session ID, and not as BBYSAuM0g4OlkKnBeowSdWSgYRfOxMTMASY8PPTXXIsDWwA6BpXT which is the actual session ID created by the WebLogic instance, before the affinity token and JVMID are appended. Since the session information is stored in a cache in Coherence using the session id as a key, no session is found matching the value that includes the affinity information, triggering the creation of a new session.
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!