weblogic jsessionid

Question

I run Weblogic 10.3 locally and have a question about the sessionId that it generates. When i print session.getId() i see something that resembles this:

BBp9TAACMTglQ2TDFAKR4tpyXg73LZDQJ2PtT9x8htG1tWY122aa!869187422!1308677666322

what are these exclamation points and what follows it, specifically the second pair: !1308677666322 ? It looks like sometimes the server appends it and sometimes it doesn't. I believe weblogic appends it if I use the same browser to login to my app for the second time. Is this cookie related somehow?

Answer 1

Looking at some randomly generated Weblogic JSessionIDs from my own application

BrYx4hyPZ4VSP9Wo4eU0OrqmhXMLFONbRHnpLFwRKZ9MSaf6wvYj!-314662473

and

BrYiFED29itaC4EBpWYM8RKVQQauHkvnTsA2OAKUPZXVc9oUD5fB!-784323496.

Now if you notice the part of the session id after the first ! i.e 314662473 and 784323496.

This number is the unique identifier that Weblogic gives to the running JVM i.e. the running Weblogic server.

If there is more than one server in your application, Weblogic knows how to route your session back to the correct server by using this 9 digit JVM number which is part of the session ID.

Each time you restart the weblogic server, it will generate a new JVM id and use it as long as that weblogic server is running. So any hits to that server will have the same ID at the end of the session ID.

The format of the session ID is:

JSESSIONID=SESSION_ID!PRIMARY_JVMID_HASH!SECONDARY_JVM_HASH!CREATION_TIME

So if the primary is not available, it will try to jump over to secondary and if you have enabled session replication - then the session data can be recovered. If you are running only a single server on local, then the format is simply

JSESSIONID=SESSION_ID!PRIMARY_JVMID_HASH!CREATION_TIME

regarding some times it does not appear, I've seen it is usually a browser dependent whether the sessionid is shown in the address bar or not

Answer 2

WebLogic Server use those IDs to maintain HTTP Session Affinity in the WebLogic Cluster In-Memory Replication model.

For those Web applications with the HTTP session replication enabled (at weblogic.xml deployment descriptor and disabled by default) WebLogic will keep a primary and a backup copy of your HTTP Session with the cluster.

To avoid cluster overhead, the WebLogic Proxy Plug-In (deployed in your Web Tier Layer) parse the session cookie and redirects every request to the WLS hosting your primary copy. In case of failure or overhead of the managed server hosting the primary session, the Proxy Plug-In redirects the request to the instance where your HTTP Session resides.

The Proxy Plugin will track a dynamic list of all the WebLogic Cluster Members as pairs (JVM IDs / IP:ports) to redirect every request appropriately.

If your app don't enable the in-memory replication feature your cookie will only include the JVM ID where your HTTP Sesion lives (the primary and unique copy).