web server - Borland Technical Publications

web server - Borland Technical Publications web server - Borland Technical Publications

techpubs.borland.com
from techpubs.borland.com More from this publisher
12.11.2014 Views

Chapter 13 13Caching of Stateful Session Beans Chapter Important The EJB Container supports stateful session enterprise beans using a highperformance caching architecture based on the Java Session Service (JSS). There are two pools of objects: the ready pool and the passive pool. Enterprise beans transition from the ready pool to the passive pool after a configurable timeout. Transitioning an enterprise bean to the passive pool stores the enterprise bean's state in a database. Passivation of stateful sessions exists for two purposes: 1 Maximize memory resources 2 Implement failover Configuring Borland's JSS implementation is discussed in Chapter 6, “Java Session Service (JSS) configuration.” This document explains the use of the properties that control the passivation and persistence of individual session objects. For documentation updates, go to www.borland.com/techpubs/bes. Passivating Session Beans At deployment time, the deployer uses the Borland Enterprise Server's tools to set a passivation timeout for the EJB Container in a particular Partition. The container regularly polls active session beans to determine when they are last accessed. If a session bean has not been accessed during the timeout period, its state is sent to persistent storage and the bean instance is removed from memory. Simple Passivation Passivation timeouts are set at the container-level. You use the property ejb.sfsd.passivation_timeout to configure the length of time a session bean can go unaccessed before its state is persisted and its instance removed from memory. This length of time is specified in seconds. The default value is five seconds. This property can be set in the partition.xml properties file for the Partition you are configuring. This file is located in: /var/domains/base/configurations/ / mos//adm/properties Edit this file to set the ejb.sfsb.passivation_timeout property. Chapter 13: Caching of Stateful Session Beans 107

Sessions in secondary storage If you set this property to a non-zero value, you can also set the integer property ejb.sfsb.instance_max for each deployed session bean in their deployment descriptors. This property defines the maximum number of instances of a particular stateful session bean that are allowed to exist in the EJB container's memory at the same time. If this number is reached and a new instance of a stateful session needs to be allocated, the EJB container throws an exception indicating lack of resources. 0 is a special value. It means no maximum set. If the maximum number of stateful sessions defined by the ejb.sfsb.instance_max property is reached, the EJB container blocks a request for an allocation of a new bean for the time defined by the integer property ejb.sfsb.instance_max_timeout. The container will then wait for the number to drop below this value before throwing an exception indicating a lack of resources. This property is defined in ms (1/1000th of second). 0 is a special value. It means not to wait and throw an exception indicating lack of resources immediately. Aggressive Passivation One of the key advantages in the use of JSS is its ability to fail over. Several containers implementing JSS can be configured to use the same persistent store, allowing them to fail over to each other. Setting up the JSS for failover is discussed in Chapter 6, “Java Session Service (JSS) configuration.” To facilitate taking advantage of the JSS failover capability, Borland provides the option of using aggressive passivation. Aggressive passivation is the storage of session state regardless of its timeout. A bean that is set to use aggressive passivation will have its session state persisted every time it is polled, although its instance will not be removed from memory unless it times out. In this way, if a container instance fails in a cluster, a recently-stored version of the bean is available to other containers using identical JSS instances communicating with the same backend. As in simple passivation, if the bean times out, it will still be removed from memory. Again, aggressive passivation is set Partition-wide using the boolean property ejb.sfsb.aggressive_passivation. Setting the property to true (the default) stores the session's state regardless of whether it was accessed before the last passivation attempt. Setting the property to false allows the container to use only simple passivation. Again, this property is set in the container's properties file partition.xml located in: /var/domains/base/configurations/ / mos//adm/properties Bear in mind that although using aggressive passivation aids in failover, it also results in a performance hit since the container accesses the database more often. If you configure the JSS to use a non-native database (that is, you choose not to use JDataStore), the loss of performance can be even greater. Be aware of the trade-off between availability and performance before you elect to use aggressive passivation. Sessions in secondary storage Most sessions are not kept in persistent storage forever after they timeout. Borland provides a mechanism for removing stored sessions from the database after a discrete period of time known as the keep alive timeout. The keep alive timeout specifies the minimum amount of time in seconds to persist a passivated session in stateful storage. The actual amount of time it is kept in the database can vary, since it is not wise from a performance standpoint to constantly poll the database for unused sessions. The actual amount of time a session is persisted is at least the value of the keep alive timeout and not more than twice the value of the keep alive timeout. 108 BES Developer’s Guide

Chapter<br />

13<br />

13Caching of Stateful Session Beans<br />

Chapter<br />

Important<br />

The EJB Container supports stateful session enterprise beans using a highperformance<br />

caching architecture based on the Java Session Service (JSS). There are<br />

two pools of objects: the ready pool and the passive pool. Enterprise beans transition<br />

from the ready pool to the passive pool after a configurable timeout. Transitioning an<br />

enterprise bean to the passive pool stores the enterprise bean's state in a database.<br />

Passivation of stateful sessions exists for two purposes:<br />

1 Maximize memory resources<br />

2 Implement failover<br />

Configuring <strong>Borland</strong>'s JSS implementation is discussed in Chapter 6, “Java Session<br />

Service (JSS) configuration.” This document explains the use of the properties that<br />

control the passivation and persistence of individual session objects.<br />

For documentation updates, go to www.borland.com/techpubs/bes.<br />

Passivating Session Beans<br />

At deployment time, the deployer uses the <strong>Borland</strong> Enterprise Server's tools to set a<br />

passivation timeout for the EJB Container in a particular Partition. The container<br />

regularly polls active session beans to determine when they are last accessed. If a<br />

session bean has not been accessed during the timeout period, its state is sent to<br />

persistent storage and the bean instance is removed from memory.<br />

Simple Passivation<br />

Passivation timeouts are set at the container-level. You use the property<br />

ejb.sfsd.passivation_timeout to configure the length of time a session bean can go unaccessed<br />

before its state is persisted and its instance removed from memory. This<br />

length of time is specified in seconds. The default value is five seconds. This property<br />

can be set in the partition.xml properties file for the Partition you are configuring. This<br />

file is located in:<br />

/var/domains/base/configurations/<br />

/ mos//adm/properties<br />

Edit this file to set the ejb.sfsb.passivation_timeout property.<br />

Chapter 13: Caching of Stateful Session Beans 107

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!