web server - Borland Technical Publications
web server - Borland Technical Publications web server - Borland Technical Publications
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
- Page 67 and 68: IIS web server to Borland web conta
- Page 69 and 70: Session management with JSS If an i
- Page 71 and 72: Managing and configuring the JSS Co
- Page 73 and 74: The Borland IIOP connector BES supp
- Page 75 and 76: Setting up your web container with
- Page 77 and 78: 66 BES Developer’s Guide
- Page 79 and 80: Web-enabling your CORBA server Impo
- Page 81 and 82: Configuring your Apache web server
- Page 83 and 84: Configuring your Apache web server
- Page 85 and 86: Web Services and Partitions ■ ■
- Page 87 and 88: Web Service providers Java:RPC prov
- Page 89 and 90: How Borland Web Services work
- Page 91 and 92: Packaging Web Service Application A
- Page 93 and 94: Tools Overview Java2WSDL tool Note
- Page 95 and 96: 84 BES Developer’s Guide
- Page 97 and 98: Client view of an enterprise bean L
- Page 99 and 100: Client view of an enterprise bean E
- Page 101 and 102: Managing transactions Managing tran
- Page 103 and 104: Support for JNDI Support for JNDI T
- Page 105 and 106: EJB to CORBA mapping A CORBA progra
- Page 107 and 108: 96 BES Developer’s Guide
- Page 109 and 110: Application Client architecture Pac
- Page 111 and 112: Document Type Definitions (DTDs) my
- Page 113 and 114: Support of references and links The
- Page 115 and 116: Use of Manifest files Use of Manife
- Page 117: 106 BES Developer’s Guide
- Page 121 and 122: 110 BES Developer’s Guide
- Page 123 and 124: Container-managed persistence and R
- Page 125 and 126: Implementing an entity bean Generat
- Page 127 and 128: Container-Managed Persistence in Bo
- Page 129 and 130: Container-Managed Persistence in Bo
- Page 131 and 132: Setting Properties Setting Properti
- Page 133 and 134: Setting Properties into a BLOB. The
- Page 135 and 136: Setting Properties Automatic table
- Page 137 and 138: 126 BES Developer’s Guide
- Page 139 and 140: Container-managed persistence and R
- Page 141 and 142: Container-Managed Persistence in Bo
- Page 143 and 144: Container-Managed Persistence in Bo
- Page 145 and 146: Container-Managed Persistence in Bo
- Page 147 and 148: Container-Managed Persistence in Bo
- Page 149 and 150: Container-Managed Persistence in Bo
- Page 151 and 152: Container-Managed Persistence in Bo
- Page 153 and 154: 142 BES Developer’s Guide
- Page 155 and 156: Setting Properties J2EE 1.3 Entity
- Page 157 and 158: Setting Properties Figure 16.2 Edit
- Page 159 and 160: Setting Properties Table 16.1 ejb.m
- Page 161 and 162: Setting Properties Table 16.3 Table
- Page 163 and 164: Setting Properties Security Propert
- Page 165 and 166: Aggregate Functions in EJB-QL Selec
- Page 167 and 168: Support for ORDER BY Support for OR
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