Ajuste del contenedor de EJB
Si utiliza aplicaciones que afecten al tamaño de la memoria caché del contenedor de EJB(Enterprise JavaBeans), es posible que el rendimiento de las aplicaciones pueda resultar afectado por un valor de tamaño incorrecto. La persistencia gestionada por contenedor (CMP) se describe en este tema, aunque es importante saber que los beans de entidad no están soportados en un módulo EJB 3.x.
Tamaño de la memoria caché de EJB
Supervisar Tivoli Performance Viewer para determinar si el valor del tamaño de memoria caché de contenedor de EJBse ha ajustado correctamente para la aplicación.
Si la aplicación ha llenado la memoria caché dando lugar a desalojos, Tivoli Performance Viewer mostrará una cadencia elevada del método ejbStores llamado y, probablemente, una utilización de procesador más baja de lo esperado en la máquina de estación de trabajo.
EJB_Cache_Size = (Número mayor de beans de entidad de la Opción B o C inscritos en una
transacción * número máximo de transacciones simultáneas) +
(Número mayor de beans de entidad de opción A exclusivos a los que se espera acceder durante
una carga de trabajo de aplicación típica) +
(Número de beans de sesión con estado activos durante una carga de trabajo
típica) +
(Número de tipos de bean de sesión sin estado utilizados durante una carga de trabajo típica)
Donde:
los beans de entidad de opción B y C sólo se mantienen en la memoria caché de EJB durante toda la duración
de la transacción en la que están inscritos. Por consiguiente, el primer término de la fórmula
calcula el promedio de los requisitos de memoria caché de EJB para estos tipos de beans.
Los beans de entidad de opción A se mantienen en la memoria caché de EJB indefinidamente y sólo se eliminan
de la memoria caché si empieza a haber más beans en la memoria caché que el valor establecido
del tamaño de la memoria caché. Si la aplicación utiliza Beans de sólo lectura, considere que sean
Beans de opción A para realizar este cálculo de ajuste.
Los beans de sesión con estado se mantienen en la memoria caché de EJB hasta que se eliminen por
la aplicación o hasta que se alcance el valor de tiempo de espera de la sesión.
Sólo se mantiene una instancia de bean de sesión sin estado para cada tipo de EJB en
la memoria caché durante el tiempo que se ejecuta cualquier método en ese bean de sesión sin
estado. Si dos o más métodos se implementan simultáneamente en el mismo
tipo de bean de sesión sin estado, cada método se ejecuta en su propia instancia de bean, pero
sólo se utiliza una única ubicación para todas estas instancias.
Esta fórmula calcula el límite superior en el número máximo de enterprise beans activos a la vez en el servidor de aplicaciones. Dado que la memoria caché del contenedor de EJB está diseñada para contener todos estos beans para la optimización del rendimiento, el mejor rendimiento se puede conseguir estableciendo que este tamaño de memoria caché sea mayor que el número resultante de la fórmula anterior.
Puede establecer el tamaño de memoria caché de EJB en la consola administrativa bajo
.Además, al ajustar el tamaño de la memoria caché de EJB, puede ajustar el parámetro de hebra de gestión de contenedor EJB para satisfacer las necesidades de la aplicación. La hebra de gestión se controla mediante el valor de Intervalo de limpieza. Este valor controla la frecuencia con la que una hebra de daemon incluida en el producto intenta eliminar instancias de bean de la memoria caché que no se han utilizado recientemente con el fin de mantener el número de instancias de bean igual al tamaño de memoria caché o por debajo. Este comportamiento garantiza que el contenedor de EJB y busca elementos en la memoria caché rápidamente. Deje este intervalo establecido en el valor predeterminado; sin embargo, en algunos casos, puede ser recomendable comprobar si existe alguna ventaja en reducir este intervalo.
Para obtener más información sobre la forma de ajustar la memoria caché de EJB utilizando el servicio de rastreo de memoria caché de EJB, consulte cómo ajustar la memoria caché de EJB y utilizar el servicio de rastreo.
Ajuste del bean de sesión con estado de EJB
El tiempo de espera de bean de sesión con estado se configura de diferentes maneras, con ámbitos diferentes, dependiendo de la versión de WebSphere Application Server.
WebSphere Application Server Versión 6.1 y anteriores da soporte a la configuración del tiempo de espera de bean de sesión con estado, por bean, mediante el archivo ibm-ejb-jar-ext.xmi.
WebSphere Application Server Versión 7.0 da soporte a la configuración de tiempo de espera de beans de sesión con estado, por bean, mediante el archivo ibm-ejb-jar-ext.xmi (para módulos EJB 2.x) y el archivo ibm-ejb-jar-ext.xml (para módulos EJB 3.x).
WebSphere Application Server versión 8.x da soporte a la configuración de tiempo de espera de beans de sesión con estado, por bean, mediante el archivo ibm-ejb-jar-ext.xmi (para módulos EJB 2.x) y el archivo ibm-ejb-jar-ext.xml (para módulos EJB 3.x), y el elemento XML stateful-timeout y la anotación @StatefulTimeout. Además, puede configurar un valor de tiempo de espera de sesión con estado en todo el servidor (global) utilizando la propiedad del sistema com.ibm.websphere.ejbcontainer.defaultStatefulSessionTimeout.

No obstante, puede existir un módulo de Java EE 5 o posterior dentro de una aplicación que incluya archivos previos a Java EE 5 y que utilice la extensión de nombre de archivo .xmi.
Los archivos ibm-webservices-ext.xmi, ibm-webservices-bnd.xmi, ibm-webservicesclient-bnd.xmi, ibm-webservicesclient-ext.xmi, y ibm-portlet-ext.xmi siguen utilizando la extensión de archivo .xmi.
sptcfgLos beans de sesión sin estado no tienen un valor de tiempo de espera excedido porque no tienen estado conversacional y no están dedicados a ningún cliente específico.
Puede utilizar Rational Application Developer para actualizar el archivo ibm-ejb-jar-ext.xmi, que se utiliza para configurar el valor de tiempo de espera de sesión con estado para beans en un módulo EJB 2.x. Si desea más información, consulte sobre cómo definir los valores de tiempo espera de sesión para un bean en el Information Center de Rational Application Developer.
<ejbExtensions xmi:type="ejbext:SessionExtension" xmi:id="SessionExtension_1"
timeout="15">
Puede modificar el archivo ibm-ejb-jar-ext.xmi para establecer el tiempo de espera de sesión con estado para los beans en un módulo de EJB 3.x. Por ejemplo, el código para establecer un valor de tiempo de espera de sesión con estado de 15 minutos para el bean myBean es:
<ejbExtensions xmi:type="ejbext:SessionExtension" xmi:id="SessionExtension"
timeout="15">
<enterpriseBean xmi:type="ejb:Session" href="META-INF/ejb-jar.xml#MyBean"/>
</ejbExtensions>
Puede configurar el tiempo de espera del bean de sesión con estado utilizando la anotación @StatefulTimeout. La anotación @StatefulTimeout toma un parámetro de valor necesario que representa la duración del tiempo de espera y un parámetro de unidad opcional. Si el parámetro de unidad opcional no se ha especificado, la unidad predeterminada es el minuto. La anotación @StatefulTimeout se presenta como parte de EJB 3.1.
Por ejemplo, utilice la anotación @StatefulTimeout para declarar un valor de tiempo de espera de 100 segundos:
@StatefulTimeout(value=100 unit=java.util.concurrent.TimeUnit.SECONDS)
Puede configurar el tiempo de espera del bean de sesión con estado utilizando el elemento XML stateful-timeout en el descriptor de despliegue ejb-jar.xml. El elemento stateful-timeout se presenta como parte de EJB 3.1.
Por ejemplo, para establecer un valor de tiempo de espera de 100 segundos:
<stateful-timeout>
<timeout>100</timeout>
<unit>Seconds</unit>
</stateful-timeout>
La anotación @StatefulTimeout y el elemento XML stateful-timeout son los mecanismos definidos por la especificación para declarar los valores de tiempo de espera por bean, empezando por EJB 3.1. Antes de EJB 3.1, no existe ninguna manera definida mediante especificación para poder declarar el tiempo de espera de sesión con estado por bean. Al utilizar el elemento XML stateful-timeout o la anotación @StatefulTimeout, el valor -1 indica que no se excede nunca el tiempo de espera del bean, mientras que el valor 0 indica que el bean es susceptible de ser eliminado inmediatamente.
Puede configurar el tiempo de espera de los beans de sesión con estado de forma global (en todo el servidor), utilizando la propiedad del sistema com.ibm.websphere.ejbcontainer.defaultStatefulSessionTimeout. La unidad de tiempo para com.ibm.websphere.ejbcontainer.defaultStatefulSessionTimeout es el minuto. El valor especificado debe ser 0 o mayor, y si se especifica un valor no válido, el valor predeterminado de 10 minutos se utiliza en su lugar. El valor de tiempo de espera global no se puede configurar utilizando XML o anotaciones. El valor de tiempo de espera global se aplica a todos los beans de sesión con estado que se ejecutan en el servidor, incluidos los beans de sesión con estado en módulos de EJB 2.x o EJB 3.x.
- Elemento XML stateful-timeout
- Anotación @StatefulTimeout
- ibm-ejb-jar-ext.xml o ibm-ejb-jar-ext.xmi
- Propiedad del sistema com.ibm.websphere.ejbcontainer.defaultStatefulSessionTimeout
- Si no hay ningún valor de tiempo de espera a nivel de bean o de todo el servidor, se aplicará el valor de tiempo de espera predeterminado de 10 minutos.
Dcom.ibm.websphere.ejbcontainer.poolSize
Si la aplicación utiliza la mayoría de las instancias de bean de la agrupación, Tivoli Performance Viewer así lo indica. Cuando esto ocurra, aumente el tamaño de las agrupaciones de beans que se están agotando al añadir este parámetro en la etiqueta de las propiedades personalizadas de la JVM; por ejemplo:
-Dcom.ibm.websphere.ejbcontainer.poolSize=<nombre_aplicación>#<nombre_módulo>#
<nombre_enterprisebean>=<tamañoMín>,<tamañoMáx>
Donde:
El elemento <application_name> es el nombre de la aplicación Java EE tal como está definido en el descriptor de despliegue del archivo EAR (enterprise archive), para el bean cuyo tamaño de agrupación se está estableciendo.
El elemento <module_name> es el nombre del archivo Java (JAR) del módulo EJB, del bean cuyo tamaño de agrupación se está estableciendo.
El elemento <bean_name> es el nombre del EJB (Java EE enterprise bean), tal como se define en el descriptor de despliegue del módulo EJB, para el bean cuyo tamaño de agrupación se está estableciendo.
El elemento <minSize> es el número de instancias de bean que el contenedor mantiene en la agrupación, independientemente de la longitud que los beans hayan tenido en la agrupación (los beans que superen este número se borran de la agrupación a lo largo del tiempo para optimizar la utilización de la memoria)
El elemento <maxSize> es el número de instancia de bean de la agrupación donde no se han colocado más instancias de bean en la agrupación después de que se hayan utilizado (es decir, cuando la agrupación tiene este tamaño, los beans adicionales se descartan en lugar de añadirlos a la agrupación, lo que asegura que el número de beans en la agrupación tiene un límite superior de forma que el uso de memoria no crezca de forma ilimitada).
Para mantener el número de instancias de la agrupación en un tamaño fijo, tamañoMín y tamañoMáx se pueden establecer en el mismo número. Hay una agrupación independiente de instancias por cada tipo EJB que se ejecute en el servidor de la aplicación, y cada agrupación comienza sin ninguna instancia; el número de instancias crece conforme se van utilizando los beans y colocándolos en la agrupación.
Dcom.ibm.websphere.ejbcontainer.poolSize=ivtApp#ivtEJB.jar#ivtEJBObject=125,1327
establecería un minSize de 125 y un maxSize de 1327 en el bean denominado ivtEJBObject dentro del archivo ivtEJB.jar de la aplicación ivtApp. La aplicación ivtApp, se sustituye por el nombre auténtico de la aplicación, el archivo ivtEJB.jar se sustituye por el archivo JAR que contenga el bean que deberá aumentar el tamaño de su agrupación, y ivtEJBObject es el nombre del bean del enterprise bean cuya agrupación debe aumentar de tamaño. El número mínimo de beans que se mantienen en la agrupación es 125. El número máximo de beans que se mantienen en la agrupación es 1327. Establezca estos valores para que no se produzcan más desalojos de la agrupación. En la mayoría de los casos estos debe establecerse igual si la memoria está muy llena ya que no se produce ningún aumento ni reducción de la agrupación.
Dcom.ibm.websphere.ejbcontainer.noPrimaryKeyMutation
Comprenda cómo la aplicación maneja la creación de objetos de clave primaria para que los utilicen los beans CMP y los beans BMP (persistencia gestionada por bean) dentro del producto.
-Dcom.ibm.websphere.ejbcontainer.noPrimaryKeyMutation=true

Las ventajas de rendimiento de esta optimización dependen de la aplicación. Si la aplicación utiliza tipos primitivos para las claves primarias de los enterprise beans, no se logra nada ya que estos objetos ya son inmutables y el mecanismo de copia lo tiene en cuenta. No obstante, si la aplicación utiliza numerosas claves primarias complejas, es decir, un objeto para una clave primaria o varios campos, este parámetro puede dar lugar a importantes mejoras.
Dcom.ibm.ws.pm.deferredcreate
El contenedor de EJB utiliza el gestor de persistencia para que persistan los datos en la base de datos de los beans de entidad CMP.

-Dcom.ibm.ws.pm.deferredcreate=true
Las ventajas de rendimiento de esta optimización dependen de la aplicación. Si las transacciones de aplicaciones EJB realizan numerosas inserciones, la aplicación puede beneficiarse de esta optimización. Si la aplicación realiza pocas inserciones, las ventajas de esta optimización serán menores.
Dcom.ibm.ws.pm.batch
Cuando una aplicación EJB accede a varios beans CMP incluidos en una única transacción, y en función de las operaciones realizadas en los beans (como actualizaciones, inserciones y lecturas), el número de operaciones emitidas a la base de datos se corresponde directamente con las operaciones realizadas en los beans CMP. Si el sistema de base de datos que está utilizando da soporte al proceso por lotes de sentencias actualizadas, puede habilitar este distintivo y aumentar el rendimiento en todas las interacciones con la base de datos que impliquen más de dos actualizaciones en una única transacción.

-Dcom.ibm.ws.pm.batch=true
Las ventajas de rendimiento de esta optimización dependen de la aplicación. Si la aplicación nunca o casi nunca actualiza los beans CMP o sólo actualiza un único bean por transacción, no se produce una mejora del rendimiento. Si la aplicación actualiza varios beans por transacción, este parámetro mejora el rendimiento de las aplicaciones.
Base de datos | Soporta la actualización por lotes | Soporta la actualización por lotes con el control de simultaneidad optimista |
---|---|---|
DB2 | sí | no |
Oracle | sí | no |
Controlador DB2 Universal | sí | sí |
Informix | sí | sí |
SQLServer | sí | sí |
Apache Derby | sí | sí |

com.ibm.ws.pm.useLegacyCache
Especifica el nombre de la clase Java que utiliza el producto para implementar la interfaz javax.rmi.CORBA.UtilDelegate.

com.ibm.ws.pm.useLegacyCache=false
com.ibm.ws.pm.grouppartialupdate y com.ibm.ws.pm.batch
La característica de actualizaciones parciales mejora el rendimiento de las aplicaciones con enterprise beans en determinados casos. El gestor de persistencia tiene dos tipos de mecanismos de memoria caché: memoria caché de legado y memoria caché de dos niveles. Normalmente la memoria caché de dos niveles tiene un mejor rendimiento que la memoria caché de legado debido a las optimizaciones de esta modalidad.

'com.ibm.ws.pm.grouppartialupdate=true' y 'com.ibm.ws.pm.batch=true'