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.

Todas las aplicaciones que utilizan enterprise beans deben tener este valor ajustado a partir del valor predeterminado si el resultado de la siguiente fórmula es superior a 2000.
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 Servidores > Tipos de servidor > Servidores de aplicaciones WebSphere > nombre_servidor > Valores de contenedor EJB > Valores de memoria caché de EJB.

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.

Supported configurations Supported configurations: Para los archivos de enlace y extensión de IBM®, la extensión del nombre de archivo .xmi o .xml es diferente en función de si se utiliza una aplicación o módulo previo a Java EE 5 o una aplicación o módulo Java™ EE 5 o posterior. Un archivo de enlace o extensión de IBM se denomina ibm-*-ext.xmi o ibm-*-bnd.xmi donde * es el tipo de archivo de extensión o enlace como app, application, ejb-jar o web. Se aplican las condiciones siguientes:
  • En el caso de una aplicación o módulo que utilice una Java EE anterior a la versión 5, la extensión del archivo debe ser .xmi.
  • En el caso de una aplicación que utilice Java EE versión 5 o posterior, la extensión del archivo debe ser .xml. Si los archivos .xmi se incluyen con la aplicación o el módulo, el producto ignora los archivos .xmi.

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.

sptcfg

Los 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.

Por ejemplo, el código XMI generado para establecer un valor de tiempo de espera de sesión con estado de 15 minutos es:
<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.

En WebSphere Application Server versión 8.x, un valor de tiempo de espera con estado a nivel de bean tiene prioridad sobre el valor de tiempo de espera a nivel de servidor. El valor de tiempo de espera en todo el servidor tiene prioridad sobre el tiempo de espera predeterminado (no especificado). El orden de prioridad siguiente se utiliza para determinar el valor de tiempo de espera de sesión con estado para un bean que se ejecute en WebSphere Application Server versión 8.x:
  1. Elemento XML stateful-timeout
  2. Anotación @StatefulTimeout
  3. ibm-ejb-jar-ext.xml o ibm-ejb-jar-ext.xmi
  4. Propiedad del sistema com.ibm.websphere.ejbcontainer.defaultStatefulSessionTimeout
  5. 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.

Cuando el contenedor necesita una instancia de bean y no hay ningún bean en la agrupación, el contenedor crea una instancia de bean, la utiliza y la coloca en la agrupación, a menos que se haya alcanzado el número máximo de instancias (maxSize) en la agrupación. Por ejemplo, la sentencia
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.

El contenedor de EJB utiliza la clave primaria de un bean de entidad como identificador dentro de las estructuras de datos internas para optimizar el rendimiento. Sin embargo, el contenedor de EJB debe copiar estos objetos de clave primaria en el primer acceso al bean para garantizar que los objetos almacenados en las memorias caché internas estén separados de los que se utilizan en una aplicación. Este proceso se produce para mantener la coherencia de las estructuras internas en caso de que la aplicación cambie o se produzca una mutación de la clave primaria. Si la aplicación no modifica ninguna de las claves primarias para crear beans de entidad y acceder a ellos después de su creación, se puede utilizar un distintivo especial que permite al contenedor de EJB pasar por alto la copia del objeto de clave primaria, ahorrando ciclos de procesador y aumentando el rendimiento. Este mecanismo puede habilitarse bajo su responsabilidad añadiendo la propiedad –D al campo de propiedades personalizadas de la JVM.
-Dcom.ibm.websphere.ejbcontainer.noPrimaryKeyMutation=true
Supported configurations Supported configurations: Los beans de entidad no están soportados en los módulos de EJB 3.x y superiores.sptcfg

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.

Al crear beans de entidad llamando al método ejbCreate, el gestor de persistencia predeterminado inserta inmediatamente la fila vacía sólo con la clave primaria en la base de datos. En la mayoría de los casos, después de la creación del bean, debe modificar los campos del bean creado o de otros beans incluidos en la misma transacción. Si desea posponer la inserción en la base de datos hasta el final de la transacción para evitar un viaje a la base de datos, establezca el distintivo –D en el campo de propiedades personalizadas de la JVM. Los datos se insertan en la base de datos y se conserva la coherencia.
Supported configurations Supported configurations: Los beans de entidad no están soportados en los módulos de EJB 3.x y superiores.sptcfg
-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.

Supported configurations Supported configurations: Los beans de entidad no están soportados en los módulos de EJB 3.x y superiores.sptcfg
Utilice este distintivo, que permite que el gestor de persistencia reúna todas las sentencias en una única sentencia por lotes, que se emite seguidamente a la base de datos. Este proceso evita recorridos completos a la base de datos, lo que aumenta el rendimiento. Si sabe que la aplicación es capaz de actualizar varios beans CMP en una única transacción y que la base de datos da soporte a las actualizaciones por lotes, puede establecer el distintivo –D en el campo de propiedades personalizadas de la JVM; por ejemplo:
-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.

La tabla siguiente lista las bases de datos de programa de fondo que dan soporte a la actualización por lotes.
Tabla 1. Bases de datos de fondo que soportan una actualización por lotes. La tabla siguiente lista las bases de datos de programa de fondo que dan soporte a la actualización por lotes.
Base de datos Soporta la actualización por lotes Soporta la actualización por lotes con el control de simultaneidad optimista
DB2 no
Oracle no
Controlador DB2 Universal
Informix
SQLServer
Apache Derby
Supported configurations Supported configurations: La actualización por lotes con OCC no se puede realizar para las bases de datos que no dan soporte a la misma, incluso si ha especificado mediante el intento de acceso.sptcfg

com.ibm.ws.pm.useLegacyCache

Especifica el nombre de la clase Java que utiliza el producto para implementar la interfaz javax.rmi.CORBA.UtilDelegate.

Supported configurations Supported configurations: Los beans de entidad no están soportados en los módulos de EJB 3.x y superiores.sptcfg
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 es más eficiente que la memoria caché antigua debido a las optimizaciones de esta modalidad. El valor predeterminado es la memoria caché de legado, aunque se recomienda la memoria caché de dos niveles. Establezca esta configuración mediante la propiedad del sistema del forma siguiente:
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.

Supported configurations Supported configurations: Los beans de entidad no están soportados en los módulos de EJB 3.x y superiores.sptcfg
En determinadas aplicaciones en las que necesita realizar actualizaciones por lotes y actualizaciones parciales, debe configurar las siguientes propiedades del sistema para beneficiarse de ambas:
'com.ibm.ws.pm.grouppartialupdate=true' y 'com.ibm.ws.pm.batch=true'

Icon that indicates the type of topic Reference topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rprf_ejbcontainer
File name: rprf_ejbcontainer.html