Contenedores de EJB

Un contenedor de EJB (Enterprise JavaBeans) proporciona un entorno de ejecución para los enterprise beans del servidor de aplicaciones. El contenedor maneja todos los aspectos de una operación de enterprise bean dentro del servidor de aplicaciones y actúa como intermediario entre la lógica empresarial escrita por el usuario en el bean y el resto del entorno del servidor de aplicaciones.

En un solo contenedor se pueden instalar uno o varios módulos, cada uno de los cuales contiene uno o varios enterprise beans.

El contenedor de EJB proporciona muchos servicios al enterprise bean, incluidos los siguientes:
  • Iniciar, confirmar y retrotraer las transacciones según sea necesario.
  • Mantener agrupaciones de instancias de enterprise bean preparadas para las peticiones de entrada y trasladar estas instancias entre las agrupaciones inactivas y un estado activo, comprobando que las condiciones de enhebramiento del bean se hayan cumplido.
  • Lo que es más importante, se sincronizan automáticamente los datos en las variables de la instancia del bean con los elementos de datos correspondientes en el almacenamiento persistente.

Al mantener dinámicamente un conjunto de instancias de beans activas y sincronizar el estado del bean con el almacenamiento persistente cuando los beans pasan de un estado activo a inactivo, el contenedor permite que una aplicación gestione muchas más instancias de bean de las que podrían mantenerse simultáneamente en la memoria del servidor de aplicaciones. En este respecto, un contenedor de EJB proporciona servicios similares a la memoria virtual dentro de un sistema operativo.

WebSphere Application Server proporciona una flexibilidad significativa en la gestión de datos de base de datos con bean de entidad. Los EJB de entidad Activate y Load en los valores de configuración especifican cómo y cuando cargar y usar la caché de los datos correspondientes de la fila de la base de datos de un enterprise bean. Estos valores de configuración proporcionan la posibilidad de especificar las opciones A, B o C de antememmoria de enterprise bean, según se describe en las especificaciones EJB 1.1. Puede configurar estos valores con herramientas de ensamblaje. Para leer más sobre cómo utilizar las herramientas de ensamblaje, consulte el Information center de herramientas de ensamblaje.

Entre transacciones, el estado de un bean de entidad se puede almacenar en la memoria caché. El contenedor de EJB da soporte a las opciones de colocación en memoria caché A, B y C.
  • Con la opción A de colocación en memoria caché, el servidor de aplicaciones presupone que el bean de entidad se utiliza en un solo contenedor. Los clientes de dicho bean deben dirigir las peticiones a la instancia de bean dentro de dicho contenedor. El bean de entidad tiene un acceso exclusivo a la base de datos subyacente, lo que significa que el bean no puede clonarse ni participar en la gestión de la carga de trabajo si se utiliza la opción A de colocación en memoria caché.
    Si tiene previsto utilizar escenarios de sólo lectura, el producto proporciona una variación alternativa de los beans de entidad de la opción A que aumenta el rendimiento. Esta opción de memoria caché se denomina Multihebra de sólo lectura. Con un comportamiento parecido al de la opción A estándar, el contenedor de EJB continúa activando el bean sólo una vez y lo deja activado hasta que el contenedor de EJB necesita espacio en la memoria caché de instancias activas. No obstante, el contenedor de EJB se diferencia de la opción A estándar en los siguientes aspectos:
    • Vuelve a cargar el estado del bean del almacenamiento persistente de forma periódica como respuesta a la invocación de un método por parte del usuario para seleccionar los cambios que se han realizado en el almacenamiento persistente desde la última vez que se cargó el bean. Puede configurar esta función mediante un valor de Intervalo de recarga en el descriptor de despliegue del bean. Para obtener más información, consulte el tema Desarrollo de beans de entidad de sólo lectura.
    • El contenedor de EJB no graba el estado del bean en el almacenamiento persistente al final de la transacción ni se invoca el método ejbStore() del bean.
    • El contenedor de EJB permite invocaciones de método desde más de un cliente (hebra) en la misma instancia de bean. Esto difiere del componente EJB estándar respecto al interior de un bean. Tenga en cuenta este aspecto cuando desarrolle el bean, y compruebe que la lógica en los métodos de empresa del bean sea siempre de hebra segura.
  • Con la opción B de colocación en memoria caché, el bean de entidad permanece activo en la memoria caché durante la transacción pero se vuelve a cargar al principio de cada llamada a método.
  • Con la opción C de colocación en memoria caché C (el valor predeterminado), el bean de entidad se vuelve a cargar siempre desde la base de datos al principio de cada transacción. Un cliente puede intentar acceder al bean e iniciar una transacción nueva en cada contenedor que se ha configurado para albergar este bean. Esto es similar al recurso de agrupación en clúster de sesiones que se ha descrito para sesiones HTTP ya que el estado del bean de entidad se mantiene en una base de datos compartida a la que se puede acceder desde cualquier servidor cuando se necesita.

La opción A proporciona un rendimiento máximo del enterprise bean mediante el uso de la memoria caché para los datos de base de datos que están fuera del ámbito de la transacción. Por lo general, la opción A sólo se aplica donde el contenedor de EJB tenga acceso exclusivo a la base de datos dada. Si no es así, la integridad de los datos se verá expuesta. La opción B proporciona un uso más agresivo de la memoria caché para las instancias de objeto EJB de entidad, lo que puede proporcionar un mejor rendimiento sobre la opción C, pero también se utilizan gran cantidad de memoria. La opción C es la más frecuente en las configuraciones reales para los EJB de entidad, y es el valor predeterminado.

El valor Activate at especifica el punto en el que se activa un enterprise bean y se coloca en la memoria caché. Con este valor se controla la memoria caché y la pasivización. Los valores válidos son Once y Transaction. El valor Once indica que el bean se activa cuando se accede al mismo por primera vez en el proceso de servidor y se pasiviza (y se elimina de la memoria caché) a discreción del contenedor, por ejemplo, cuando la memoria caché se haya llenado. El valor Transaction indica que el bean se activa al inicio de una transacción y se pasiviza (y se elimina de la memoria caché) al final de la transacción. El valor predeterminado es Transaction.

El valor Load at especifica cuándo carga el bean su estado desde la base de datos. El valor de esta propiedad implica si el contenedor tiene acceso exclusivo o compartido a la base de datos. Los valores válidos son Activation y Transaction. Activation indica que el bean se carga cuando se activa, e implica que el contenedor tiene acceso exclusivo a la base de datos. Transaction indica que el bean se carga al iniciar la transacción e implica que el contenedor tiene acceso compartido a la base de datos. El valor predeterminado es Transaction. Los valores de las propiedades Activate at y Load at rigen las opciones de compromiso que se utilizan. Para la opción A (acceso exclusivo de base de datos), utilice Activate at = Once y Load at = Activation. Esta opción reduce la entrada/salida de la base de datos, evitando llamadas a la función ejbLoad, pero serializa todas las transacciones que acceden a la instancia del bean. La opción A puede aumentar el uso de memoria manteniendo más objetos en la memoria caché, pero puede proporcionar mejor tiempo de respuesta si a las instancias de bean no se accede generalmente por parte de varias transacciones.
Importante: Cuando se utiliza WebSphere WebSphere Application Server, Network Deployment y la gestión de carga de trabajo está habilitada, la opción A no se puede utilizar.

Debe utilizar los valores que tengan como resultado el uso de las Opciones B y C. La opción B (acceso compartido a base de datos) utiliza Activate at = Once y Load at = Transaction. La opción B puede aumentar el uso de la memoria manteniendo más objetos en la antememoria. No obstante, como cada transacción crea su propia copia de un objeto, podría haber varias copias de una instancia en memoria en un momento dado (una por transacción), lo que precisa que haya que acceder a la base de datos para cada transacción. Si un enterprise bean contiene un número significativa de llamadas a la función ejbActivate, el uso de la opción B puede ser adecuado, ya que el objeto necesario ya está en la antememoria. En caso contrario, esta opción no proporciona ninguna ventaja significativa sobre la opción A. Para la opción C (acceso compartido de base de datos), utilice Activate at = Transaction y Load at = Transaction. Esta opción puede reducir el uso de la memoria manteniendo menos objetos en la memoria caché. No obstante, puede haber múltiples copias de una instancia en memoria en un momento determinado (una por transacción). Esta opción puede reducir la competencia entre las transacciones para los instancias de enterprise bean a las que se accede de forma concurrente, pero no se actualizan.

Este producto dar soporte a la clonación de los objetos locales de beans de sesión con estado entre diferentes servidores de aplicaciones. Sin embargo, no da soporte a la clonación de una instancia específica de un bean de sesión con estado. Cada instancia de un bean de sesión con estado específico puede existir simplemente un solo servidor de aplicaciones y sólo puede accederse a la misma dirigiendo las peticiones a este servidor de aplicaciones determinado. La información de estado de un bean de sesión con estado no se puede mantener entre varios miembros de un clúster de servidores. No obstante, la habilitación de la sustitución por anomalía de beans de sesión con estado y la configuración del contenedor de EJB para que utilice la duplicación de memoria a memoria permite duplicar la sustitución por anomalía de beans de sesión con estado en otros servidores del clúster, de forma que la sustitución por anomalía se puede ejecutar en el servidor de copia de seguridad si el servidor principal de un bean de sesión con estado se detiene por alguna razón. Para obtener más información sobre la sustitución por anomalía de beans de sesión con estado, consulte el tema sobre sustitución por anomalía de beans de sesión con estado para el contenedor de EJB.

De forma predeterminada, un contenedor de EJB se ejecuta en la modalidad de inicio rápido. La lógica de arranque del contenedor de EJB retrasa la carga y el proceso de todos los tipos EJB excepto los beans controlados por mensajes, ya que deben existir antes de que se les envíen los mensajes; los beans de arranque, que se deben procesar al arrancar el servidor y los tipos EJB que se especifican para inicializarse cuando se inicie el servidor. .

Las demás inicializaciones de EJB se retrasan hasta que se utilice por primera vez el tipo EJB. Al utilizar interfaces locales, el primer uso se produce al ejecutar un método InitialContext.lookup para el tipo. En las interfaces remotas, se produce cuando se llama al primer método en un EJB o su factoría.


Icon that indicates the type of topic Concept topic



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