weblogic jsessionid
我在本地运行 Weblogic 10.3，并对它生成的 sessionId 有疑问。当我打印 session.getId() 时，我看到类似这样的内容：
BBp9TAACMTglQ2TDFAKR4tpyXg73LZDQJ2PtT9x8htG1tWY122aa！869187422！1308677666322
这些感叹号是什么以及后面是什么，特别是第二对： !1308677666322 ？看起来服务器有时会附加它，有时则不会。我相信如果我使用相同的浏览器第二次登录我的应用程序，weblogic 会附加它。这个cookie有什么关系吗？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
查看我自己的应用程序中随机生成的一些 Weblogic JSessionID
，
现在，如果您注意到会话 ID 第一个之后的部分！，即
314662473和784323496。该数字是 Weblogic 为正在运行的 JVM（即正在运行的 Weblogic 服务器）提供的唯一标识符。
如果您的应用程序中有多个服务器，Weblogic 知道如何使用这个 9 位 JVM 编号（会话 ID 的一部分）将您的会话路由回正确的服务器。
每次重新启动 weblogic 服务器时，它都会生成一个新的 JVM id，并在该 weblogic 服务器运行时使用它。因此，对该服务器的任何命中都将在会话 ID 末尾具有相同的 ID。
会话 ID 的格式为：
JSESSIONID=SESSION_ID!PRIMARY_JVMID_HASH!SECONDARY_JVM_HASH!CREATION_TIME
因此，如果主要不可用，它将尝试跳转到辅助，如果您启用了会话复制 - 那么会话数据可以恢复。
如果您在本地仅运行一个服务器，那么格式只是
JSESSIONID=SESSION_ID!PRIMARY_JVMID_HASH!CREATION_TIME ，
有时它不会出现，我发现它通常取决于浏览器是否sessionid是否显示在地址栏中
Looking at some randomly generated Weblogic JSessionIDs from my own application
and
Now if you notice the part of the session id after the first ! i.e
314662473and784323496.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
WebLogic Server 使用这些 ID 来维护 WebLogic 群集内存复制模型中的 HTTP 会话关联性。
对于那些启用了 HTTP 会话复制（在 weblogic.xml 部署描述符中，默认情况下禁用）的 Web 应用程序，WebLogic 将在集群中保留 HTTP 会话的主副本和备份副本。
为了避免集群开销，WebLogic 代理插件（部署在 Web 层中）会解析会话 cookie 并将每个请求重定向到托管主副本的 WLS。如果托管主会话的托管服务器出现故障或开销，代理插件会将请求重定向到 HTTP 会话所在的实例。
代理插件将跟踪所有 WebLogic 集群成员的动态列表（JVM ID / IP：端口），以适当地重定向每个请求。
如果您的应用程序未启用内存中复制功能，您的 cookie 将仅包含 HTTP 会话所在的 JVM ID（主要且唯一的副本）。
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).