let's we have the code to get session as follows.
HttpSession session = request.getSession();
Object myObj = session.getAttribute("myObjKey");
If want to replicate the session during clustering weblogic instances, need to modify weblogic.xml as follows.
<?xml version='1.0' encoding='UTF-8'?>
<weblogic-web-app xmlns="http://www.bea.com/ns/weblogic/weblogic-web-app"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/weblogic-web-app http://www.bea.com/ns/weblogic/weblogic-web-app/1.0/weblogic-web-app.xsd">
<session-descriptor>
<persistent-store-type>replicated_if_clustered</persistent-store-type>
<sharing-enabled>true</sharing-enabled>
</session-descriptor>
<container-descriptor>
<prefer-web-inf-classes>true</prefer-web-inf-classes>
</container-descriptor>
<context-root>/mycontext</context-root>
</weblogic-web-app>
-- persistent-store-type
Sets the persistent store method to one of the following options:
-
memory
—Disables persistent session storage. -
replicated
—Same asmemory
, but session data is replicated across the clustered servers. - replicated_if_clustered—If the Web application is deployed on a clustered server, the in-effect
persistent-store-type
will be replicated. Otherwise,memory
is the default. - async-replicated—Enables asynchronous session replication in an application or web application. See Configuring Session Persistence.
- async-replicated-if-clustered—Enables asynchronous session replication in an application or web application when deployed to a cluster environment. If deployed to a single server environment, then the session persistence/replication defaults to in-memory. This allows testing on a single server without deployment errors.
-
file
—Uses file-based persistence (See also persistent-store-dir). -
async-jdbc
—Enables asynchronous JDBC persistence for HTTP sessions in an application or web application. See Configuring Session Persistence. -
jdbc
—Uses a database to store persistent sessions. (see also persistent-store-pool). - cookie—All session data is stored in a cookie in the user’s browser.
Enables Web applications to share HTTP sessions when the value is set to
true
at the application level. -- prefer-web-inf-classes
if set to true, will cause classes located in the WEB-INF directory of a Web application to be loaded in preference to classes loaded in the application or system classloader. The default value is false. A value specified in the console will take precedence over a value set manually.
-- context-root
The context-root element defines the context root of this stand-alone Web application. If the Web application is part of an EAR, not stand-alone, specify the context root in the EAR’s META-INF/application.xml file. A context-root setting in application.xml takes precedence over context-root setting in weblogic.xml.
- Check application.xml for context root; if found, use as Web application’s context root.
- If context root is not set in application.xml, and the Web application is being deployed as part of an EAR, check whether context root is defined in weblogic.xml. If found, use as Web application’s context root. If the Web application is deployed standalone, application.xml does not come into play and the determination for context-root starts at weblogic.xml and defaults to URI if it is not defined there.
- If context root is not defined in weblogic.xml or application.xmll, then infer the context path from the URI, giving it the name of the value defined in the URI minus the WAR suffix. For instance, a URI MyWebApp.war would be named MyWebApp.
Note: | The context-root element cannot be set for individual Web applications in EAR libraries. It can only bet set for Web application libraries. |
Session Management Best Practices
ReplyDelete- Use HttpSession as temporary storage for your application state data; not a replacment for database. As much as possible limit the session usage only to state cannot be cached using alternate mechanisms.
- Use only Serializable objects in HttpSession.
Use only getAttribute() / setAttribute() to put & fetch session data.
- Use In Memory state management as much as possible.
- Collate multiple session attributes which are read/updated together into a single Entity before persisting in the session. For example, instead of storing item and quantity as separate attributes; group them into an OrderVO and store.
Similalry; instead of having the overhead of serializing and deserializing big VOs; split the VO into 'read-only' and 'read-write' attributes. For instance, it makes sense to split OrderState and OrderAddress into two separate value objects before storing in the session.
Nice Post, very useful.
ReplyDeleteFor more documents on weblogic server, please check the link below:
http://www.wikiconsole.com/wiki/?page_id=3908
Regards,
www.wikiconsole.com