Skip to main content

Deployment - Session-Descriptor Parameters

Below list of will help you to configure cookies and do session related settings. You can do these settings at application or server level.

1. timeout-secs
Sets the time, in seconds, that WebLogic Server waits before timing out a session. The default value is 3600 seconds.
On busy sites, you can tune your application by adjusting the timeout of sessions. While you want to give a browser client every opportunity to
finish a session, you do not want to tie up the server needlessly if the user has left the site or otherwise abandoned the session.
This element can be overridden by the session-timeout element (defined in minutes) in web.xml.
2. invalidation-interval-secs
Sets the time, in seconds, that WebLogic Server waits between doing house-cleaning checks for timed-out and invalid sessions,
and deleting the old sessions and freeing up memory. Use this element to tune WebLogic Server for best performance on high traffic sites.
The default value is 60 seconds.
3. sharing-enabled
Enables Web applications to share HTTP sessions when the value is set to true at the application level.This element is ignored if turned on at the Web application level.The default value is false.
4. debug-enabled
Enables the debugging feature for HTTP sessions.The default value is false.
5. id-length
Sets the size of the session ID. The minimum value is 8 bytes and the maximum value is Integer.MAX_VALUE.If you are writing a WAP application, you must use URL rewriting because the WAP protocol does not support cookies. Also, some WAP devices have a 128-character limit on URL length (including attributes), which limits the amount of data that can be transmitted using URL re-writing. To allow more space for attributes, use this attribute to limit the size of the session ID that is randomly generated by WebLogic Server.You can also limit the length to a fixed 52 characters which is default value, and disallow special characters, by setting the WAPEnabled attribute.
For more information, see
URL Rewriting and Wireless Access Protocol in Developing Web Applications for WebLogic Server.
6. tracking-enabled
Default true. Enables session tracking between HTTP requests.
7. max-in-memory-sessions
Sets the maximum limit for memory/replicated sessions.Without the ability to configure bound in-memory servlet session use, as new sessions are continually created, the server eventually throws out of memory. To protect against this, WebLogic Server provides a configurable bound on the number of sessions created. When this number is exceeded, the weblogic.servlet.SessionCreationException occurs for each attempt to create a new session. This feature applies to both replicated and non-replicated in-memory sessions.To configure bound in-memory servlet session use, you set the limitation in the max-in-memory-sessions element.The default is -1 (unlimited).
8. cookies-enabled
Default true.Use of session cookies is enabled by default and is recommended, but you can disable them by setting this property to false. You might turn this option off to test.
9. cookie-name
Defines the session tracking cookie name. Defaults to JSESSIONID if not set. You may set this to a more specific name for your application.
10. cookie-path
Default null. Defines the session tracking cookie path.If not set, this attribute defaults to / (slash), where the browser sends cookies to all URLs served by WebLogic Server. You may set the path to a narrower mapping, to limit the request URLs to which the browser sends cookies.
11. cookie-domain
Default null. Specifies the domain for which the cookie is valid. For example, setting cookie-domain to.mydomain.com returns cookies to any server in the *.mydomain.com domain.
The domain name must have at least two components. Setting a name to *.com or *.net is not valid.
If not set, this attribute defaults to the server that issued the cookie.
For more information, see Cookie.setDomain() in the Servlet specification from Sun Microsystems.
12. cookie-comment
Default null. Specifies the comment that identifies the session tracking cookie in the cookie file.
13. cookie-secure
Default false. Tells the browser to only send the cookie back over an HTTPS connection. This ensures that the cookie ID is secure and should only be used on Websites that use HTTPS. Session Cookies over HTTP no longer work if this feature is enabled.You should disable the url-rewriting-enabled element if you intend to use this feature.
14.cookie-max-age-secs
Sets the life span of the session cookie, in seconds, after which it expires on the client.
The default value is -1 (unlimited)
For more information about cookies, see Using Sessions and Session Persistence
15. persistent-store-type
Sets the persistent store method to one of the following options:
memory — Disables persistent session storage.
replicated — Same as memory, 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.
sync-replication-across-cluster — The replication will occur synchronously across the cluster.
async-replication-across-cluster — The replication will occur asynchronously across the cluster.
file — Uses file-based persistence (See also PersistentStoreDir, above).
jdbc — Uses a database to store persistent sessions. (see also persistent-store-pool, above).
cookie — All session data is stored in a cookie in the user's browser.
16. url-rewriting-enabled
Enables URL rewriting, which encodes the session ID into the URL and provides session tracking if cookies are disabled in the browser.Default value is true

17. http-proxy-caching-of-cookies
Default true. When set to false, WebLogic Server adds the following header with the following response:"Cache-control: no-cache=set-cookie" This indicates that the proxy caches do not cache the cookies.

18. encode-session-id-in-query-params
Default false. The latest servlet specification requires containers to encode the session ID in path parameters. Certain Web servers do not work well with path parameters. In such cases, the encode-session-id-in-query-params element should be set to true. 

Comments

Popular posts from this blog

Passivation and Activation in ADF (Application Module )

1. For performance reasons, ADF keeps a pool of application modules in memory. It tries to give each session the same application module as the session used during the last request; however, this might not be possible during peak load of your application. 2. In this case, ADF saves the application modules state in a database table so the application module can be used by another session. This is called passivation . 3. When the first session needs the application module again, its state is retrieved from the database process known as activation . 4. If you have made an error in your code and depend on some variable that is not persisted correctly when your application module state is stored, you will experience mysterious errors under high load.   Enable/Disable Application Module Pooling : Right-click on your application module, choose Configurations.By default, each application module has two configurations. Ensure that the one ending in …Local is selected and then click

Get modified rows from Entitiy Cache

To get the modified rows from entity cache we have getEntityState() method at EntityImpl class. Refer to my previous blog  Accessing EO impl methods from VO impl  where i am overriding the getEntityState() in EOimpl and calling it in VOImpl. We can use methods written or overridden in VOImpl class to AMImpl class. There are different states associated with an entity object. STATUS_UNMODIFIED STATUS_MODIFIED STATUS_NEW STATUS_DELETED STATUS_DEAD We have to check the state or row in our AmImpl class by using the VOImpl method and through this we can distinguish the rows present at vo. Add below code in AMImpl class along with my previous post. public void geCachedRowsCount(){         JobsVOImpl jobsVo = (JobsVOImpl)this.getJobsVO();         RowSetIterator iter = jobsVo.createRowSetIterator(null);             while(iter.hasNext()){             Row row = iter.next();             byte state = jobsVo.getEntityState(row);             System.out.println("Job_id -&

The file store "WLS_DIAGNOSTICS" could not be opened

WLS_DIAGNOSTIC ERROR weblogic.store.PersistentStoreException: [Store:280073]The file store "WLS_DIAGNOSTICS" could not be opened because it contained a file with the invalid version 1. A file of version 2 was expected. When you get this error while running your application on internal weblogic server delete the following file WLS_DIAGNOSTICS000000.DAT search the file in following path C:\jdev_work\system11.1.1.5.37.60.13\DefaultDomain this file is in DefaultDomain folder of your jdev. and delete the WLS_DIAGNOSTICS000000.DAT file . and run your applicatuon