Story Transcript
Oficina Técnica para la Gestión y Supervisión de Servicios TIC Subdirección de Tecnologías de la Información
Best practices de desarrollo sobre Oracle Weblogic Server para la capa de negocio
Referencia documento: InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc Fecha: 13 de enero de 2011 Versión: 2.1.0
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
Registro de Cambios Fecha
Autor
Versión
Notas
13 de enero de 2011
Emilio Nestal
2.0.0
Versión inicial
Revisiones Nombre
Role
Jonathan Ortiz
Advanced Support Engineer
Copia
Nombre
Empresa
1
Subdirección de Tecnologías de la Información Servicio de Coordinación de Informática de la Consejería de Innovación
Servicio Andaluz de Salud, Junta Andalucía Consejería de Innovación, Junta Andalucía
Distribución
2
de de
Pág. 2 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
Índice de Contenidos
CONTROL DE CAMBIOS .........................................................................................................................5 INTRODUCCIÓN ....................................................................................................................................6 OBJETIVOS DE ESTE DOCUMENTO ..........................................................................................................7 BEST PRACTICES DE DESARROLLO SOBRE WEBLOGIC SERVER ...............................................................8 BEST PRACTICES PARA JDBC ................................................................................................................9 Tecnología JDBC ..............................................................................................................................9 Drivers JDBC ....................................................................................................................................9 Arquitectura JDBC ......................................................................................................................... 10 Consideraciones sobre los drivers JDBC ....................................................................................... 11 Pool de Conexiones ......................................................................................................................... 11 Data Sources ................................................................................................................................... 12 PinnedToThread.............................................................................................................................. 14 Batch Updates ................................................................................................................................. 15 Gestión de transacciones ................................................................................................................ 15 Niveles transaccionales ................................................................................................................... 15 BEST PRACTICES PARA JAVA MESSAGE SERVICE................................................................................. 17 Dos tipos de dominios JMS ............................................................................................................. 18 Arquitectura JMS ............................................................................................................................ 18 Operativa de clientes JMS .............................................................................................................. 19 Agregación y flujo de mensajes ....................................................................................................... 19 Persistent Stores .............................................................................................................................. 19 Paging ............................................................................................................................................. 20 Tamaño del buffer del mensaje ....................................................................................................... 20 Throttling ........................................................................................................................................ 21 Cuotas JMS ..................................................................................................................................... 22 Umbrales o threshold ...................................................................................................................... 23 Control de flujo ............................................................................................................................... 23 Gestión de expirados ....................................................................................................................... 24 Acuse de recibo (Acknowledgement) ............................................................................................... 25 Store and Forward (SAF)................................................................................................................ 26 BEST PRACTICES PARA ENTERPRISE JAVABEANS ................................................................................ 28 Interfaces EJB ................................................................................................................................. 28 Estructura de aplicaciones EJBs..................................................................................................... 29 Beans de tipo Stateless Session ....................................................................................................... 29 Message-Driven Beans (MDB) ....................................................................................................... 31 Stateful Session Beans ..................................................................................................................... 32 Beans de entidad (Entity beans) ...................................................................................................... 36 Estrategias de concurrencia para Entity Beans .............................................................................. 39 Entity Bean Bulk Updates ............................................................................................................... 41 Cacheo de relaciones (relationship caching) .................................................................................. 42 Container-Managed Transactions (CMT)....................................................................................... 44 BEST PRATICES PARA CLUSTERING ...................................................................................................... 48 Balanceo de carg y failover ............................................................................................................ 48 Arquitectura básica de un clúster ................................................................................................... 49 Arquictura multi capa de un clúster ................................................................................................ 49 Balanceadores de carga .................................................................................................................. 50
Pág. 3 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
Replicación de sesión ...................................................................................................................... 51 Replicación basada en memoría ..................................................................................................... 51 Persistencía basada en JDBC ......................................................................................................... 52 Persistencía basada en file system compartido ............................................................................... 52 Configuración de los tipos de replicación ...................................................................................... 52 BEST PRACTICES PARA WORK MANAGERS .......................................................................................... 54 Default Work Manager ................................................................................................................... 54 Clases de tipo Request .................................................................................................................... 54 Clases de tipo Fair Share Request .................................................................................................. 55 Clases de tipo Response Time Request ........................................................................................... 55 Clases de tipo Context Request ....................................................................................................... 55 Resctricciones (Constraints) ........................................................................................................... 56 Resctricción Maximum Threads ...................................................................................................... 56 Resctricción Minimum Threads ...................................................................................................... 56 Resctricción Capacity ..................................................................................................................... 57 Clases y restricciones de tipo Referencing...................................................................................... 57 Global-Level Work Managers ......................................................................................................... 57 Work Manager a nivel de aplicación .............................................................................................. 58 Work Managers a nivel de aplicaciones Web ................................................................................. 58 Work Manager para Stuck Threads ................................................................................................ 59 Colas de ejecución (Execute queues) .............................................................................................. 59
Pág. 4 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
Control de cambios Cambio
Descripción
Página
Pág. 5 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
Introducción Este documento recoge una serie de recomendaciones de Oracle Soporte planteadas como buenas prácticas de desarrollo para aplicaciones que hagan uso de Oracle WebLogic Server 11gR1. Estas recomendaciones están encaminadas a minimizar los posibles problemas de rendimiento en sistema de cualquier tamaño y en la gran mayoría de los casos se basan en la experiencia de casos reales gestionados por Oracle Soporte. Finalmente, este documento también recoge una serie de conceptos de componentes, módulos y tecnologías relacionadas con Oracle WebLogic Server 11gR1., que a juicio de Oracle Soporte, deberían tenerse claros para asegurar la aplicación de las recomendaciones recogidas en este documento, y de manera general, entender los productos Oracle sobre los que se sustentan los sistemas y aplicaciones.
Pág. 6 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
Objetivos de este documento A lo largo de los puntos de este documento se irá definiendo una guía de buenas prácticas para el desarrollo de aplicaciones sobre Oracle WebLogic Server 11gR1. Esta guía contendrá tanto prácticas recomendadas como prácticas a evitar y se apoyará en ejemplos y en información que permita analizar las recomendaciones en cada uno de los entornos de desarrollo y preproducción. Este documento se centra principalmente en las versiones Oracle WebLogic Server 11gR1, aunque algunas de las recomendaciones son igualmente aplicables a las versiones anteriores. El objetivo de esta guía de buenas prácticas tiene varios objetivos: Aprovechamiento de las características del producto o
Rendimiento
o
Escalabilidad
o
Alta disponibilidad
o
Balanceo de carga
Facilitar la implantación y modificación del aplicativo en producción con sistemas basados en Oracle WebLogic Server 11gR1.
Pág. 7 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
Best practices de desarrollo sobre Weblogic Server Versión Objetivo Bussiness Layer
Pág. 8 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
Best Practices para JDBC Tecnología JDBC JDBC es una API que proporciona una interfaz común de programación para el acceso a diferentes bases de datos. JDBC lleva a cabo las conexiones a las bases de datos mediante un driver que transforma llamadas de JDBC en llamadas nativas a la base de datos. La independencia de plataforma es una característica inherente de Java conseguida por la máquina virtual. Las aplicaciones que utilizan JDBC no tienen que preocuparse de la arquitectura de la máquina o del sistema operativo, ya que esto es abstraído por la máquina virtual. Java proporciona un amplio soporte para la gestión de objetos remotos a través de su Remote Method Invocation API y Enterprise Java Beans. Esto permite a los desarrolladores, centrase más en los procesos de gestión de datos y menos en cuestiones particulares del sistema (transparencia de ubicación). JDBC se ha convertido en una API para el acceso a cualquier tipo de forma de manejo de datos como hojas de cálculo, ficheros planos y por supuesto, de bases de datos. JDBC está basado en el estándar de facto ODBC de Microsoft. ODBC por su parte, está basado en la especificación X/Open CLI. ODBC está disponible para Windows y puede ser accedido mediante C, C++, Visual Basic y muchos otros lenguajes. Mientras que ODBC simplemente una API a nivel de C, JDBC representa una capa completa orientada a objeto de acceso a bases de datos. Ya que JDBC sigue de cerca el funcionamiento de ODBC, se puede implementar un driver JDBC sobre un driver ODBC (un “puente” JDBCODBC), que fue lanzado al mercado por INTERSOLV.
Drivers JDBC Los drivers JDBC drivers son clases de implementación para operaciones de bases de datos. Podemos dividir los drivers en dos categorías: • Two-tier, donde el cliente se comunica directamente con la base de datos. • Three-tier, donde el cliente se comunica con una capa intermedia, normalmente Weblogic Server, que delega a una base de datos
Pág. 9 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011 Los drivers JDBC drivers son una simple colección de clases que implementan métodos conocidos y definidos por las especificaciones del driver JDBC. Estos drivers se dividen en dos clases: two-tier y three-tier. Los drivers Two-tier se usan por un cliente, independientemente de qué cliente es, para accede a una base de datos directamente. En un driver three-tier, WebLogic Server actúa como capa intermedia, optimizando las conexiones para la base de datos, normalmente mediante un pool de conexiones. Un pool de conexiones es una colección de conexiones a una base de datos. WebLogic Server crea as conexiones de un pool de conexiones en tiempo de arranque. Estas conexiones se configuran para usar un driver JDBC en particular y para conectarse a una base de datos específica. El gráfico anterior, muestra cómo las aplicaciones pueden conectarse directamente a una base de datos usando JDBC ó usando Weblogic Server, que a su vez utiliza JDBC, para la conexión.
Arquitectura JDBC Las aplicaciones que usan JDBC pueden usar uno de los cuatro tipos de drivers JDBC distintos. El primer tipo de driver es el puente JDBC-ODBC. El programa Java accede a la base de datos a través de una conexión ODBC client-configured. Una aplicación cliente, puede incluso usar un driver JDBC que tiene acceso al driver nativo de la API instalado en el lado del cliente para una base de datos particular
Pág. 10 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011 Un driver de tipo 2, proporciona un puente desde la API Java JDBC hasta el driver native instalado en el cliente. El driver nativo tiene los protocolos para comunicarse directamente con la base de datos. El driver de tipo 3, ó implementación multi-capa, utiliza un servidor de red para pasar las peticiones JDBC a la base de datos. Un driver de tipo 4 es una implementación Java del driver nativo JDBC de la base de datos. La base de datos y la aplicación JDBC realizan llamadas Java-to-Java usando este tipo de driver. Los drivers JDBC que permiten a una máquina cliente comunicarse directamente con la base de datos se llaman implementaciones de dos capas (two-tier), mientras que al driver de tipo 3 se le llama implementación multi capa.
Consideraciones sobre los drivers JDBC La elección del tipo de driver correcto es tan importante que puede tener una gran influencia en el rendimiento. Un driver de Tipo 2 no es necesariamente más rápido. El driver Thin de Oracle 10g es significativamente más rápido que el driver Thin de 9i.
Pool de Conexiones Una de las ventajas de usar un pool de conexiones sobre una conexión directa es que las conexiones ya existirán cuando las aplicaciones quieran conectarse a una base de datos. Esto ahorra a las aplicaciones la sobrecarga de la creación de conexiones. Incluso el software de la capa intermedia, Weblogic Server, puede aplicar un balanceo de carga mediante la asignación de conexiones a aplicaciones usando una base de datos, y luego liberando y poniéndolas disponibles para otras aplicaciones cuando no estén en uso. El balanceo de carga puede incluso incluir un crecimiento y una reducción dinámica del número de conexiones en un pool de conexionespara adptarse a condiciones de cambio de cargas. El pool de conexiones añade otras ventajas como la aplicación de seguridad a una conexión.
El gráfico muestra que el servidor de aplicaciones aloja el pool de conexiones y que las aplicaciones utilizan los pools en función de sus necesidades.
Pág. 11 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
Data Sources Un data source es un concepto J2EE que permite abstraer una conexión JDBC. Con un data source, un desarrollador o administrador puede especificar un objeto que representa una base de datos. En el caso de WebLogic Server, un data source contiene y gestiona un pool de conexiones. Un usuario puede acceder a un data source y usarlo para crear una conexión a la base de datos via el pool de conexiones asociado con el data source. El concepto de data source permite a los desarrolladores despreocuparse completamente del pool de conexiones o de la base de datos que se emplean para crear la conexión.
El gráfico muestra como las aplicaciones Java usan JNDI para obtener una referencia a un data source. Esto lo hace con la llamada lookup(). La aplicación Java toma después una conexión del data source usando una llamada al método getConnection(). A partir de ese momento, la aplicación Java está lista para hacer llamadas a la base de datos usando esa conexión.
Tamaño del Pool de Conexiones Capacidad Inicial: El número de conexiones físicas a crear cuando se crea un pool de conexiones. Es también el número mínimo de conexiones físicas que el pool de conexiones mantendrá disponibles. Capacidad Máxima: El número máximo de conexiones físicas que el pool de conexiones puede contener. Incremento de Capacidad: El número de conexiones creadas al añadir nuevas conexiones al pool de conexiones. Cuando no hay más conexiones físicas disponibles para satisfacer las peticiones de conexión, WebLogic Server crea este número de conexiones físicas adicionales y las añade al pool de conexiones.
Shrink Frequency WebLogic Server reduce periódicamente el pool de conexiones a su capacidad inicial en function del uso. El parámetro Shrink Frequency se usa para especificar el número de segundos a esperar antes de reducer un pool de conexiones. Si está a 0, shrinking está deshabilitado. Esto puede ser muy útil en un entorno de producción.
Pág. 12 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
Testeo de conexiones Test Connection On Reserve: Habilita a WebLogic Server para hacer un test sobre una conexión antes de dársela a un cliente. El test añade un pequeño retraso en la petición del cliente para una conexión del pool, pero asegura que el cliente reciba una conexión viable. Test Frequency: El número de segundos que pasa entre los tests que realiza WebLogic Server sobre conexiones que no se están usando. Las conexiones que fallan en el test se cierran y se vuelven a abrir para intentar reestablecer una conexión física válida. Si se pone a 0, estos tests periódicos se deshabilitan. Nota: Ambos parámetros requieren que se le indique un nombre de tabla para el test y sobre la que se realizará un consulta de tipo SQL, select * from .
Row Prefetch El row prefetching mejora el rendimiento al cargar multiples filas del servidor al cliente en un único acceso. El tamaño óptimo del prefetch depende de las particularidades de la consulta. En general, el incremento del tamaño suele mejorar el rendimiento, hasta que se alcance un valor particular. Row Prefetch Enabled: Habilita la precarga de multiples filas (es decir, las que se envían desde el servidor al cliente) en un acceso al servidor. Cuando un cliente externo accede a una base de datos usando un driver JDBC a través de WebLogic Server, el row prefetching mejora el rendimiento mediante la precarga de múltiples filas desde el servidor al cliente en un solo acceso. WebLogic Server ignora esta opción y no usa la precarga cuando el cliente y WebLogic Server están en la misma JVM. Tamaño del Row Prefetch: Si está habilitado el row prefetching, especifica el número de filas que se precargan. El tamaño óptimo del prefetch depende de las particularidades de la consulta. En general, el incremento del tamaño suele mejorar el rendimiento, hasta que se alcance un valor particular. En este caso, no tendríamos una mejora muy significativa en el rendimiento. Muy raramente conseguiremos mejorar el rendimiento al exceder de 100 filas. Los valores mínimo y máximo para este parámetro son respectivamente 2 y 65536.
Cacheo de sentencias Un objeto de tipo sentencia JDBC o statement se usa para enviar sentencias SQL a la base de datos al igual que un objeto de tipo JDBC PreparedStatement se usa para enviar sentencias SQL precompiladas con uno o más parámetros. Los objetos PreparedStatement se usan para sentencias SQL que se usan de forma repetida con posibles variaciones en las variables, y al estar precompiladas se aumenta el rendimiento de dichas llamadas. En el caso de llamadas a procedimiento y funciones almacenadas, es necesario usar otro tipo de objetos, JDBC CallableStatement. El comportamiento de Weblogic Server en cuanto a la funcionalidad de cacheo de sentencias puede controlarse a través del parámetro Statement Cache Type. Es
Pág. 13 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011 parámetro define el algoritmo usado para mantener las sentencias preparadas almacenadas en el statement cache. Las opciones son: •
LRU, es decir, cuando llega una sentencia nueva, ya sea de tipo prepared o tipo callable statement, la sentencia menos usada es reemplazada por la nueva en la caché.
•
FIXED, es decir, se cachean las N primeras sentencias, ignorando el resto respecto al cacheo.
Para determinar el tamaño de la caché, Weblogic Server usa el parámetro Statement Cache Size, que permite determinar el número de prepared y callable statements que se almacenan en caché. Dos características adicionales para esta característica: •
Cada conexión en el pool de conexiones tiene su propio cache de sentencias.
•
Si se indica un valor de Statement Cache Size igual a 0, se deshabilita esta opción.En caso contrario, los valores mínimo y máximo para este parámetro son respectivamente 0 y 1024.
PinnedToThread PinnedToThread es una opción que puede mejorar el rendimiento al permitir que las execute threads mantengar la conexión a base de datos incluso después de que la aplicación cierre la conexión lógica. Cuando PinnedToThread está habilitado, WebLogic Server fija una conexión del pool de conexiones a la hebra la primera vez que ésta reserva la conexión. En el momento que la aplicación termina de usar la aplicación e invoca a connection.close(), devolviendo la conexión al pool, Weblogic Server mantiene esta relación y no la devuelve realmente. Cuando la aplicación a través de la hebra vuelve a realizar una petición a base de datos, ya tiene disponible una conexión a ésta. Un efecto de esta configuración, es que se reduce la potencial contención que se crea cuando múltiples hebras intentan reservar una conexión en un momento del tiempo y existen suficientes conexiones dentro del pool para todas ellas. En este caso, donde la aplicación reserva más de una conexión dentro de una misma hebra de ejecución, Weblogic Server creará una conexión adicional y la mantendrá asociada a dicha hebra gracias a esta funcionalidad.
Pág. 14 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
Batch Updates Una aplicación típica puede llegar a ejecutar una gran cantidad de sentencias de manipulación de datos, operaciones de tipo insert, update o delete. Este tipo de situaciones, se pueden obtener benecificios si: • Las combinamos de forma apropiada podremos mejorar el rendimiento. • Usamos Statement.addBatch() y Statement.executeBatch() para realizar operaciones por lotes o batching updates.
Gestión de transacciones La gestión de la transaccionalidad de una aplicación pueden requerir un esfuerzo extra por parte de sistemas con el fin de evitar situaciones de inconsistencias y/o corrupciones por parte de los datos que maneja una aplicación. En el caso de las bases de datos, las transacciones consumen y mantienen muchas clases de recursos en uso para asegurar que se aplican las propiedades ACID, es decir, atomicidad, consistencia, aislamiento y durabilidad, a una transacción. Con el fin de reducir esta carga extra de trabajo, se puede recomendar que, en la medida de lo posible, múltiples transacciones se unifiquen dentro del menor número de transacciones posibles. Por defecto, las conexiones JDBC trabajan en modo auto-commit, lo que significa que todas las operaciones enviadas a la base de datos se ejecutan automáticamente como una transacción separada. Al deshabilitar el auto-commit e indicando explícitamente los límites de las transacciones se puede conseguir mejorar el rendimiento de las aplicaciones. Para ello, basta con utilizar simplemente la sentencia JDBC siguiente: Connection.setAutoCommit(false) La API de JDBC proporciona también el método Connection.getAutoCommit() que devuelve el valor actual del modo auto-commit. Cuando se deshabilita el autocommit, sera necesario el uso de los métodos Connection.start(), Connection.commit() y Connection.rollback().
Niveles transaccionales El nivel de aislamiento de una transacción suele definirse como el balanceo de las siguientes características: • •
La integridad de los datos frente a La velocidad de acceso concurrente
En base a este balanceo se establecen cuatro nieveles transaccionales: •
TRANSACTION_READ_UNCOMMITTED
Pág. 15 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011 • • •
TRANSACTION_READ_COMMITTED TRANSACTION_REPEATABLE_READ TRANSACTION_SERIALIZABLE
Como veremos, cuando más alta es la integridad de los datos, más lento es el acceso. Estos dos aspectos pueden ser controlados por el nivel de aislamiento de la transacción. Pero ¿a qué nos referimos con integridad? Cuando hay un problema con la integridad significa que hay una discrepancia entre los datos de dos transacciones. A continuación tenemos varios escenarios que muestran problemas de integridad: • • •
Dirty reads: Una fila ha sido modificada por otro proceso y esa modificación no ha hecho commit aún. Non-repeatable read: Una fila ha sido modificada por otro proceso que ha confirmado la modificación.. Phantom row: Un fila ha sido eliminada por otro proceso, y el borrado no ha sido confirmado aún.
Volviendo a los cuatro niveles de aislamiento transaccionales: •
TRANSACTION_READ_UNCOMMITTED: Se permiten Dirty reads, nonrepeatable read y phantom reads. Es el nivel más permisivo.
•
TRANSACTION_READ_COMMITTED: No se permiten las dirty reads. Sin embargo, si están permitidas las non-repeatable reads y las phantom reads.
•
TRANSACTION_REPEATABLE_READ: No se permiten las dirty reads nil as non-repeatable reads. Las Phantom reads si están permitidas.
•
TRANSACTION_SERIALIZABLE: No se permiten Dirty reads, non-repeatable read ni phantom reads. Es el nivel más restricctivo.
Pág. 16 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
Best Practices para Java Message Service Un sistema orientado a mensajería es aquel que a través de un sistema de mensajería, permite el intercambio de información entre procesos basándose en mensajes. Java Message Service (JMS) el API estandar para el acceso a sistema de mensajería en Java. Sin embargo hay que tener en cuenta que JMS no es un proveedor de servicio ó un servidor Message-Oriented Middleware (MOM). Es simplemente un conjunto de interfaces que definen un estándar de Java para acceder a productos de tipo Enterprise Messaging (EM). Por tanto, a través de JMS : • Se permite a las aplicaciones Java compartir un sistema de mensajes para el intercambio de mensajes. •
Se simplifica el desarrollo de las aplicaciones proporcionando una interfaz estándar para la creación, envío y recepción de mensajes
El gráfico muestra cómo dos programas pueden estar desacoplados gracias a un sistema MOM, done el proveedor de datos pone el mensaje en él y el consumidor toma dicho mensaje y lo procesa. La especificación JMS define muchos aspectos de los mensajes, como su formato y su interacción con los distintos proveedores de servicios. Sin embargo, la especificación JMS no se ocupa de temas como: • • • • • •
Balanceo de Carga Tolerancia a fallos Notificación de errores Administración Seguridad e integridad de los mensajes Protoco de envoi para mensajes binarios
El gráfico muestra que los clientes JMS son aplicaciones conectadas al sistema MOM, es decir, tanto el emisor como el receptor del mensaje son considerados clientes JMS.
Pág. 17 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
Dos tipos de dominios JMS La especificación JMS define dos dominios accesibles: el dominio punto a punto, point-to-point o PTP. y el dominio proveedor/consumidor, publish/subscribe o pub/sub. La especificación JMS clasifica en terminos generales todos los productos de mensajería en uno de estos dominios. • •
Un ejemplo de dominio point-to-point es una aplicación que envía un mensaje de log a una cola, que es escrito a un fichero de texto por otro proceso. Un ejemplo de dominio publish/subscribe es una aplicación que publica el valor de una acción en mútiples sistemas de venta de acciones que previamente estaban suscritos.
El gráfico muestra como en la mensajería point-to-point el mensaje solo es recibido por un único cliente o receptor. En el caso de publish/subscribe, el mensaje llega a varios consumidores o suscriptores.
Arquitectura JMS JMS es una API para el acceso a sistemas de mensajería empresarial. JMS permite a las aplicaciones Java compartir un sistema de mensajería para el intercambio de mensajes. Simplifica el desarrollo de aplicaciones proporcionando una interfaz estándar para la creación, envío y la recepción de mensajes. En este ámbito de JMS, JNDI se usa para crear un contexto inicial para una connection factory de tipo JMS, que se usará para crear conexiones a proveedores de servicio basados en JMS.
Pág. 18 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011 El gráfico muestra que para que un proveedor pueda enviar un mensaje, necesitamente previamente crear un connection factory y una conexión con el servidor JMS. Un objeto ConnectionFactory encapsula información de configuración de conexiones y habilita a las aplicaciones JMS para la creación de conexiones. Cuando se establece la conexión, se invoca a una sesión que habilita al proveedor para enviar el mensaje al destinatario.
Operativa de clientes JMS Una llamada desde un cliente JMS a un servidor MOM implica los siguientes pasos: • • • • • •
Crear una connection factory desde el servicio de nombres (JNDI) Usarla para crear la conexión JMS. Usar la conexión para crear una sesión. Acceder a los destinos, ya sean de tipo queue o de tipo topic a través de JDNI. Usar la sesión y el destino para establecer si se va a producir o consumir mensajes. Crear y enviar mensajes o recibir y consumir mensajes.
Agregación y flujo de mensajes Existen ocasiones donde desde un mismo punto y con el mismo destino se envian varios mensajes asíncronos. En esta situación es recomendable agruparlos y enviarlos en un único envio ya que: • • • •
Esto implica que el servidor JMS agregue las peticiones concurrente de una mismo cliente en una única operaciones de E/S. Los mensajes pueden ser entregados a través de listeners de mensajes. Se permite múltiples mensajes en una misma llamada de red. Puede parametrizarse la cantidad maxima de mensajes a través de la connection factory.
Persistent Stores Si el número de mensajes almacenados incrementa, el almacenamiento necesario para persistir los mensajes se incrementay por tanto, aumenta la cantidad de memoria necesaria para la ejecución de WebLogic Server. Los componentes JSM de Weblogic Server pueden almacenar mensajes de forma persistente en un almacenes basados en archivos ó en un base de datos a través de JDBC. Veamos a continuación comparación entre ambas opciones: • • • •
Ambos tienen la misma semántica de transacciones y garantías Ambos tienen la misma interfaz de aplicación. Los almacenes de archivos suelen ser generalmente más rápidos y fáciles de configurar. Los almacenes de archivos son más flexibles para el volcado o paging de mensajes no que no es necesario persistir.
Pág. 19 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011 •
Los almacenes JDBC pueden hacer más fácil las labores de recovery en caso de fallos ya que, al almacenarse en una base de datos, lo mas probable que se encuentre en otra máquina de la red.
Persistencia basada en ficheros En el caso de la persistencia basada en ficheros es necesario definir la política de escritura síncrona que se va a emplear. Esta política afecta en el rendimiento de los almecenes JMS, en la escalabilidad y en la fiabilidad general del sistema. Las opciones de política válidas son: •
Direct-Write, donde las escrituras en el almacen se hacen directamente a disco. Esta política está soportada en Oracle Solaris, HP-UX, y MS Windows. En este último caso, MS Windows, esta opción generalmente es más rápida que la opción de Cache-Flush.
•
Disabled, donde las transacciones se completan tan pronto como se cachean sus escrituras en memoria, en lugar de esperar a que las escrituras alcancen al disco. Esta política es la más rápida, pero la menos fiable desde el punto de visdta transaccional. Puede ser más de 100 veces más rápido que otras políticas, pero los cortes de luz ó fallos del sistema operativo pueden causar pérdidas ó mensajes duplicados.
•
Cache-Flush, donde las transacciones no se pueden completar hasta que todas las escrituras se envíen a disco. Esta política es fiable y escala bien cuando el número de usuarios simultáneos incrementa.
Paging Durante situaciones de gran carga de mensajes, éstos se paginan en disco para conservar memoria. En esta situación, hay que tener en cuenta que: •
Para mejorar el rendimiento, se recomienda que el directorio de paginación debe ser diferente del persistent store o almacen del servidor JMS.
•
Una paginación excesiva podría degradar el rendimiento.
•
Se puede minimizar la paginación mediante: Incremento el tamaño del buffer del mensaje Incremento del tamaño de heap de la JVM Usando técnicas de throttling
La paginación está siempre habilitada en WebLogic Server. Si no se especifica un directorio de paginación, los cuerpos de los mensajes a paginar se escriben en el directorio por defecto /tmp que se encuentra dentro del subdirectorio servername del directorio principal del dominio.
Tamaño del buffer del mensaje
Pág. 20 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011 La opción Message Buffer Size especifica la cantidad de memoria que se usará para almacenar el cuerpo de los mensajes en memoria antes de que se paginen a disco. EL valor por defecto de Message Buffer Size es aproximadamente un tercio del maximum heap size para la JVM, con un máximo de 512 megabytes. Cuanto más grande es este parámetro, más memoria consumirá los servidores JMS cuando haya mensajes esperando en queues o topics. Una vez que se cruce este umbral, el servidor JMS podrá escribir los cuerpos de los mensajes a un directorio especificado por la opción Paging Directory con la intención de reducir el uso de memoria. Es importante destacar que este parámetro no es una quota. Si el número de mensajes en el servidor supera el umbral, el servidor escribirá mensajes a disco y los desaloja de memoria tan rápido como puede para reducir el uso de ésta. Sin embargo, no parará de aceptar nuevos mensajes. Esto no impide que se acabe la memoria si los mensajes siguen llegando más rápido de lo que tardan en ser paginados. Por tanto, los servicios con una alta carga de mensajes deben considerar fijar una quota, ó un umbral, y habilitar control de flujo para reducir el uso de memoria en el servidor.
Throttling El tráfico de mensajes bajo condiciones de un alto volumen puede ser impredecible y producirse a diferentes ritmos de llegada y salida: En esta situación: •
Los mensajes se pueden producir mucho más rápido de los que tardan en consumirse, causando una congestión.
•
Esta condición requiere que el mensaje que se envía pase por el control de flujo.
•
El throttling también aborda el problema de que los productores saturen a los consumidores, compartan o no los mismos recursos.
En la mayoría de los sistemas de mensajes, el emisor del mensaje es más rápido que el receptor, ya que normalmente tiene que hacer menos trabajo. Sin embargo, el receptor tiene una carga de trabajo superior, ya que tiene que enviar un ACK o acknowledge, por cada mensaje que recibe. Si no está limitado, este desequilibrio puede llevar a condiciones de desbordamiento de tiempo de respuesta que pueden causar incluso que la instancia de WebLogic Server se quede sin memoria.
Técnicas para la implementación de throttling La implmentación de Weblogic Server de JMS proporciona las siguientes técnicas de throttling: •
Configuración de cuotas de mensajes, la configuración de cuotas ayuda a evitar que el servidor se quede sin memoria.
Pág. 21 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011 •
Tuning flow control: El control de flujo es configurable a través de una connection factory. A partir de Weblogic Server 7.0 se proporciona control de flujo para frenar a posibles productores excesivamente activos. Este control de flujo tiene efecto cuando se sobrepasa el umbral de mensajes configurables aunque también puede expecificarse en número de bytes. Es esta situación, se fuerza a los producers a ir más lento mediante el retraso inducido en las llamadas que producen el mensaje de respuesta.
•
El diseño de aplicaciones usando un patrón de tipo petición/respuesta: El patrón de petición/respuesta es un método efectivo y común de throttling que se incorpora al diseño de una aplicación. En esta técnica, el que hace la petición se bloquea, y no puede enviar otro mensaje hasta que reciba una respuesta del receptor.
•
Incremento del blocking send timeout: Los servidores JMS de Weblogic Server bloquean temporalmente el envío de operaciones por parte del productor si se alcanza un valor de cuota. Si la cuota se alcanza durante el tiempo que el productor envia el mensaje, éste tendrá éxito. Esto mejora el rendimiento de aplicaciones que reintentan enviar el mensaje una vez alcanzada la quota. Por defecto, los produces bloquean hasta 10 mensajes.
•
Configuración de política de expiración de mensajes: Se dice que un mensaje expira, si este es consumido, borrado, o es redirigido a otro destinatario. Se puede usar esta característica para aliviar las condiciones de desbordamiento, ya que provoca la limpieza y eliminación de los mensajes más antiguos.
Cuotas JMS Máximo número de bytes. Define el número total de bytes que pueden ser almacenados en un destinatario que usa esta cuota. Un valor de 0, significa que no se pueden enviar mensajes a un destinatario sin exceder la quota. Un valor de -1 evita que WebLogic Server imponga un límite. Es importante recordar que un volumen excesivo de bytes puede causar una saturación de memoria, Oracle recomienda que el máximo corresponda con la cantidad de memoria del sistema disponible después de contabilizar las aplicaciones desplegadas y su consumo de memoria.
Número máximo de mensajes Define el número máximo de mensajes que pueden ser almacenados en un servidor JMS. Un valor de -1 elimina cualquier límite por parte de WebLogic Server. Es importante recordar que un volumen excesivo de bytes puede causar una saturación de memoria, Oracle recomienda que el máximo corresponda con la cantidad de memoria del sistema disponible después de contabilizar las aplicaciones desplegadas y su consumo de memoria.
Pág. 22 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
Política de bloqueo de envíos (Blocking Send Policy) Determina si el servidor JMS de Weblogic Server puede entregar los mensajes más pequeños antes que los más grande cuando un destinatario ha excedido si número máximo de mensajes. Por tanto, a través de esta técnica, desactivamos la política FIFO que impide que el servidor JMS entregue mensajes pequeños cuando haya mensajes grandes ya esperando por espacio, al permitir que los mensajes pequeños se adelanten a los grandes cuando hay espacio suficiente para mensajes pequeños en el destinatario. Esta política se define sólo en el servidor JMS, no se puede establecer en los destinatarios individuales.
Tamaño máximo de mensaje Define el número máximo de bytes permitido en mensajes individuales en un servidor JMS de Weblogic Server. El tamaño de un mensaje incluye el cuerpo del mensaje, cualquier propiedad definida por el usuario y los campos de las cabeceras definidos por el usuario como JMSCorrelationID y JMSType.
Umbrales o threshold Se define bytes threshold high, como el umbral superior, en número de bytes almacenados en este servidor JMS, que lanza el control de flujo y los eventos. Un valor de -1 deshabilita los eventos para este servidor JMS. En cuando a bytes threshold low, se define como el umbral inferior, en número de bytes almacenados en este servidor JMS, que lanza el control de flujo y los eventos. Un valor de -1 deshabilita los eventos para este servidor JMS. Igualmente pude definirse por número de mensajes, a través de messages threshold high y messages threshold low.
Control de flujo Flow Maximum El número máximo de mensajes por segundo permitido para un productor que está experimentando una condición de umbral (threshold condition). Cuando se controla el flujo de un productor, nunca podrá sobrepasar el número FlowMaximum de mensajes por segundo. Si un productor no está limitando su flujo cuando se alcanza una condición umbral, el límite de flujo inicial se fija en FlowMaximum. Si un productor ya está limitando su flujo cuando se alcanza una condición umbral (el límite de flujo es inferior a FlowMaximum), el productor continuará con su límite hasta la próxima vez que se evalúe el flujo. Flow Minimum
Pág. 23 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011 El número mínimo de mensajes por segundo permitido por un productor que está experimentando una condición umbral. Es el límite inferior de flujo de un productor. Esto es, WebLogic JMS no relentizará a un productor que haya alcanzado el umbral de FlowMinimum. Flow Interval El período de tiempo, en segundos, mientras que un productor ajusta su flujo desde el número FlowMaximum de mensajes hasta el FlowMinimun, ó viceversa. Flow Steps El número de pasos cuando un productor ajusta su flujo desde una cantidad de mensajes Flow Maximum a una cantidad de mensajes Flow Minimum, ó viceversa. El Flow Interval se divide entre el número de pasos (por ejemplo, 60 segundos divididos entre 6 pasos dan 10 segundos por paso). Flow Control Enabled Especifica si un productor creado usando una connection factory permite control de flujo. Si está activado, los productores de mensajes correspondientes, reducirán su velocidad si un servidor JMS o un destino alcanzan su umbral máximo.
Gestión de expirados La política de expiración define qué acción debe tomar un destinatario en caso de que se encuentre un mensaje expirado. La política puede descartar el mensaje, descartar el mensaje y registrar su eliminación, o redireccionar el mensaje a un destinatario alternativo. No se recomienda el uso del parámetro Expiration Logging Policy ya que se considera en estado deprecated en esta versión de WebLogic Server 10g y superiores. En su lugar, Oracle recomienda el uso de Message Life Cycle Logging, que proporciona una vista más comprensiva de los eventos básicos por los que pasarán los mensajes JMS una vez que son aceptados por un servidor JMS, incluyendo datos detallados de la expiración del mensaje.
Configuración de políticas de expiración Las plantillas JMS proporcionan una forma eficiente de definir múltiples destinatarios, sean topics o queues, con características y ajustes similares. Si se usan plantillas JMS para configurar múltiples destinatarios, se puede usar el campo Expiration Policy para configurar una política de expiración en todos los destinatarios. Para anular o modificar la política de expiración para destinatarios específicos, se puede modificar a nivel de cada destinatario de forma particular. Para configurar una política de expiración de mensaje en una plantilla existente para los destinatarios, se puede seleccionar uno de las siguientes opciones de la lista de Políticas de Expiración en la página Delivery Failure de la pestaña de Configuración: •
Discard: Elimina los mensajes expirados del sistema de mensajes. La eliminación de mensajes no se registra, y los mensajes no se redirigen a otra ubicación.
Pág. 24 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011 •
Log: Elimina los mensajes expirados y escribe una entrada en el archivo de log del servidor indicando que los mensajes se han eliminado del sistema. Esta característica ha sido declarada como deprecated.
•
Redirect: Mueve los mensajes expirados de su ubicación actual al destino definido como Error Destination para el destinatario.
Escaneo de mensajes expirados La política de expiración definirá la cantidad de tiempo en que los mensajes expirarán y lo que ocurre una vez que expiran. Sin embarego, los mensajes no se eliminan necesariamente del sistema ni se moverán a un nuevo destinatario llegado este momento. Para ello, se puede configurar un servidor JMS para explorar activamente los mensajes expirados de los diferentes destinos. Para definir esto, se puede especificar el valor, en segundos, en el campo Expiration Scan Interval de la pestaña General en sobre la pestaña de Configuración. El valor especificado en este campo es la cantidad de tiempo que se quiere que el servidor JMS se pause entre sus ciclos de escaneo de destinatarios para el procesado de mensajes expirados. El valor por defecto es 30 segundos, los que significa que el servidor JMS espera 30 segundos entre cada intervalo de exploración. Para deshabilitar la exploración, introducir un valor de 0 segundos. Los mensajes expirados se eliminarán de forma pasiva del sistema cuando se descubran.
Acuse de recibo (Acknowledgement) Se recomienda usar las póliticas de acuse de recibo DUPS_OK_ACKNOWLEDGE y AUTO_ACKNOWLEDGE ya que poseen un mejor rendimiento que la pólitica CLIENT_ACKNOWLEDGE. Es importante destacar que: •
Ambos AUTO_ACKNOWLEDGE y DUPS_OK_ACKNOWLEDGE garantiza la entrega de mensajes, pero el mecanismo de doble acuse de recibo a pesar de tener un mejor rendimiento posee el coste de que ocasionalmente se pueda duplicar un mensaje.
•
Hay que diferenciar entre los acuses de recibo o acknowledgments JMS y las operaciones de commits.
Para establecer el modo de acuse de recibió, o acknowledgement mode, se debe realizar en tiempo de creación del objeto de sesión desde la conexión, tal como se muestra a continuación: Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
Pág. 25 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
Store and Forward (SAF) Store and forward (SAF) es un mecanismo asíncrono de comunicación que permite a un proveedor pueda enviar un mensaje a un consumidor en un lugar remoto, independientemente de la disponibilidad del elemento remoto. En esta situación, el mensaje se almacenará en un almacen persistente o persistent store o en memoria del punto local y se reenviará al punto remoto cuando éste esté disponible. Otra de las funcionalidades que SAF permite, es el envio de mensajes a aplicaciones distribuidas en otras instancias de Weblogic Server. Por ejemplo, la aplicación A se ejecuta en un Weblogic Server local y se comunica con la aplicación B que se ejecuta en otro Weblogic Server remoto. Las aplicaciones A y B pueden desconectarse dado que la red no es totalmente segura. En esta situación, la aplicación A envía un mensaje a la aplicación B usando un servicio SAF de Weblogic Server, el mensaje se almacenará bien en un almacen bien en la memoria del servidor local. Posteriormente el mensaje se enviará a la aplicación B cuando esté disponible. SAF usar un sistema unificado de subsistemas de almacenamiento de Weblogic Server 10g y posteriors. A través de este subsistema, ya sea en fichero o en base de datos, el almacen se creará para el servicio SAF de Weblogic Server. Los servicios SAF de Weblogic Server pueden ser usados tanto por aplicaciones JMS como por aplicaciones que usen Web Services Reliable Messaging (WA-RM). En el primer caso, los productores locales JMS pueden enviar mensajes a destinos JMS remotos. En el segundo, en los servicios SAF de tipo WSRM, los Web Services pueden estar en Weblogic Server separados para intercambiar mensajes. Las ventajas de SAF son: •
Habilita una entrega rápida y fiable de mensajes en las aplicaciones que corren en WebLogic Server
•
Asegura la entrega secuencial de mensajes mediante el mecanismo Unit-ofOrder
•
Es transparente a las aplicaciones que lo usan.
Las desventajas de SAF son: •
No puede reenviar mensajes a versiones anteriores de WebLogic Server 10g.
•
No puede interoperar con productos JMS de terceros.
Ajuste de rendimiento para servicios SAF Intervalo de Ventana Un agente emisor de mensajes esperará para reenviar el mensaje de tipo batch hasta que: •
El número de mensaje en la fuente destino es mayor o igual que el tamaño configurado como Window Size. Pág. 26 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011 •
Ha esperado el tiempo indicado a través del parámetro Window Interval, lo que suceda antes.
El intervalo de ventana, Window Interval, tiene efecto y mejora el rendimiento sólo en casos donde el que reenvía está capacitado para reenviar mensajes tan rápido como lleguen. En este caso, en lugar de reenviar inmediatamente los nuevos mensajes que llegan, el que reenvía, se pausa en un intento de acumular más mensajes y reenviarlos como un proceso por lotes. Tamaño de Ventana Para WS-RM, se define como el número máximo de mensajes no confirmados, o unacknowledged messages, permitido entre una fuente y un destino durante una conversación. En caso de definirse, un agente emisor debe esperar para reenviar un mesaje de tipo batch hasta que el número de mensajes en la fuente destino sea mayor ó igual que este valor.
Pág. 27 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
Best Practices para Enterprise JavaBeans La especificación Enterprise JavaBeans (EJB) es una especificación de arquitectura de componentes que define la estructura de beans, la estructura de contenedores en los cuales operan, y los métodos para la interacción con sus clientes. Infraestructura de servicios, implementación de servidor de aplicaciones y la implementación del cliente se definen por los desarrolladores y por el fabricante del servidor de aplicaciones. Para más información sobre EJBs y para ver la especificación visitar http://java.sun.com/products/ejb/index.html. Cada EJB tiene un enfoque de diseño en particular y unos requerimientos para su construcción. Se pueden obtener muchos beneficios teniendo una buena variedad de tipos de EJB. Las diferencias entre los tipos de EJB permiten al servidor de aplicaciones optimizar el rendimiendo siendo capaz de hacer estimaciones sobre el estado y el nivel de persistencia del componente. Los EJBs que no tienen gestión del estado pueden tener un mayor grado de pooling que los EJBs que tienen estado. Los tres niveles de conducta que un componente puede asumir son: • • •
No mantener el estado entre las peticiones de los clientes como lo EJBs stateless session o los EJBs de tipo message-driven. Mantener el estado, pero no persistente, como los EJB stateful session. Persistente, como los EJBs de entidad.
Interfaces EJB Excepto los de tipo message-driven, los EJBs tienen las siguientes interfaces que un cliente puede usar: • •
Home interface Local Home interface Remote interface Local interface
Pág. 28 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
Estructura de aplicaciones EJBs Una aplicación EJB está compuesta por • •
Es una archivo JAR Uno o más EJBs.
Estructura mínima de una aplicación EJB estándar es la siguiente: EJBFiles.class \relative\path\of\package\name\EJBFiles.class \META-INF\ejb-jar.xml \META-INF\weblogic-ejb-jar.xml En el caso de uso de beans de entidad será necesario el archivo que configura opciones específicas de WLS: \META-INF\weblogic-cmp-rdbms-jar.xml
Beans de tipo Stateless Session El tipo de bean de tipo stateless session poseen las siguientes características: • • • • • • •
Proporcionan servicios no conversacionales No mantiene ningún estado del cliente con el que dialogan. Son síncronos No sobreviven a una caida del servidor que los atiende. Se mantienen en memoria Las instancias pueden ser cacheados y reusados entre diferentes peticiones. Dos clientes no pueden acceder a una misma instancia de forma concurrente.
Gestión del pool Un contenedor de servidor de aplicaciones puede precrear y mantener EJBs de tipo stateless session y hacer que sean reutilizables por diferentes clientes. Aunque múltiples clientes pueden solicitar el uso de EJB de tipo stateless session, no es necesario que el contenedor cree una instancia para cada cliente ya que lo normal es que optimice el número de instancias que mantiene para hacer el servidor más escalable.
La especificación EJB indica que una sesión EJB sólo puede ser accedida por un cliente en cualquier momento. Esto significa que si un contenedor sólo creó una instancia EJB y hay 10 clientes solicitando el uso de dicha instancia, sólo un cliente
Pág. 29 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011 podrá acceder al mismo tiempo. El resto de los clientes deberán bloquearse y esperar a que el primer cliente termine de usar EJB de tipo stateless session. En caso de uso por parte de un cliente, éste no puede mantener el control de un bean para siempre. Hay un período de timeout, RMI request timeout, después del cual, la llámada al método falla y el bean queda libre de nuevo. El gráfico anterior muestra cinco clientes intentando acceder a un EJB en un contenedor. Dado que el pool para este tipo se ha dijado para un máximo de tres beans, dos de los clientes se bloquearán en espera del acceso.
El gráfico anterior muestra el flujo de creación de un stateless EJB en el pool, como lo avandona para atender una aplicación, permanecindo en estado ocupado, par posteriormete volver al pool para ser inactivado. Cuando Weblogic Server arranca crea y publica el pool de EJBs libres con la cantidad de instancias que se han indicadp a traves del elemento de despliegue initial-beansin-free-pool en el fichero weblogic-ejb-jar.xml. Por defecto, este valor es 0. Cuando la llamada al método se completa, la instancia EJB se devuelve al pool libre. Dado que WebLogic Server desvincula al bean del cliente después de cada llamada, la instancia que un cliente usa puede cambiar de invocación en invocación. Si todas las instancias de una clase EJB están activas y se alcanza el max-beans-infree-pool, las nuevas peticiones de clientes sobre las clases EJB se quedarán bloqueadas hasta que un EJB activo complete la llamada al método. Si la transacción caduca o, para llamadas no transaccionales, pasan mas de cinco minutos, WebLogic Server lanza una RemoteException al cliente remoto o una EJBException para el cliente local. Tamaño del pool Cuando se elige el valor para initial-beans-in-free-pool y max-beans-in-free-pool, hay que balancear el consumo de memoria con el retraso procido en la aplicación debido a la creación de los instancias necesarias. Si el número de EJBs de tipo stateless session es muy alto, el pool contiene instancias inactivas que consume memoria. Si el número es muy bajo, un cliente puede no obtener una instancia cuando lo necesite.
Pág. 30 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011 Normalmente max-beans-in-free-pool debe ser igual al número de hebras en la instancia del servidor, de forma, que cuando una hebra intente completar una petición, siempre exista una instancia disponible. Configuración del pool de EJBs stateless session Por defecto, no existen instancias EJB de tipo stateless session en WebLogic Server en el momento de arranque. Como los clientes acceden a los beans individualmente, WebLogic Server inicializa nuevas instancias de EJB a medida que las necesita. Sin embargo, si se quiere que existan instancias inactivas de EJB en WebLogic Server cuando se arranca, hay que especificar el número en el descriptor de despliegue initial-beans-in-free-pool en el archivo weblogic-ejb-jar.xml. Esto puede mejorar el tiempo inicial de respuesta cuando los clientes acceden a EJBs, porque las peticiones iniciales de los clientes se pueden satisfacer mediante la activación del bean desde el free pool, en lugar de inicializarlo y luego activarlo. Por defecto, initial-beans-in-free-pool está a 0. El tamaño máximo del free pool se limita por la memoria disponible o por el valor del elemento de despliegue max-beans-in-free-pool. InsuranceQuoteBean 15 5 ...
Message-Driven Beans (MDB) Los Message-driven beans se introdujeron como parte de la especificación EJB 2.0. Estos beans se comportan de manera similar a los beans de tipo stateless session, pero son asíncronos. Los componentes síncronos son aquellos que implementan un bloqueo y esperan su comportamiento. Por ejemplo, cuando un cliente invoca a un método en un bean stateless session, la aplicación cliente se bloquea y espera a que el bean complete la ejecución. La aplicación cliente no puede continuar hasta que el bean haya acabado. En cambio, en un modelo asíncrono, un cliente puede invocar un bean y no tener que esperar a que el método se complete antes de continuar con otras actividades. Los Message-driven beans son componentes asíncronos que desacoplan lo beans de sus usuarios. Los MDB dependen en gran medida de los conceptos de mensajería que se definen como parte de la especificación JMS. La especificación JMS define un conjunto de interfaces que abstraen los detalles de implementación de sistemas middleware orientados a mensajes. Los clientes JMS envían mensajes a destinatarios JMS
Pág. 31 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011 alojados en servidores de aplicaciones. La publicación de mensajes es una actividad muy ligera para los clientes. Despues de publicar un mensaje, al cliente no le importa como es direccionado y entregado. El servidor JMS es el responsable de esta tarea. En este ámbito, los MDBs son EJBs especiales encargados de recibir los mensajes enviados de los clientes JMS.
El gráfico muestra un cliente entregando mensajes en un destinatario JMS y a su vez los mensajes son consumidods por diferentes MDBs.
Configuración del pool para MDBs Se puede gestionar el pool de MDB bien limitando el número de instancias o bien definiendo un tamaño inicial del pool, tal como se muestra a continuación. InsuranceQuoteBean 15 5 ...
Stateful Session Beans Los Stateful session beans son muy similares a los stateless session beans, hasta tal punto que se implementan exactamente de la misma manera. Sin embargo, los beans stateful session se ocupan de mantener el estado del cliente a través de múltiples llamadas, al almacenando las propiedades de estado en los atributos del propio componente. Un contenedor EJB es el responsible de, en subsecuentes llamadas, enrutar la petición al mismo bean stateful que almacena su información de estado.
Gestión del pool Weblogic Server permite controlar cuantas instancias de stateful session EJB puede haber en memoria por cada tipo de EJB en un instante de tiempo, estableciendo umbrales por tipo de EJB. No se puede fijar ningún umbral que aplique a un grupo de tipos de EJBs juntos. Además, sólo se puede controlar el número de EJBs que se permiten en cache—no
Pág. 32 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011 hay mecanismos para controlar la cache, por ejemplo, por la cantidad de memoria ocupada por la suma de las instancias. Con este nivel de gestión de caché, hay que contestar a estas preguntas: • •
¿Cómo de grande se quiere la caché? ¿Qué ocurre con los EJB cuando la caché se llena?
El gráfico muestra que el servidor de aplicaciones alojará los stateful session beans hasta el número especificado en la opción max-beans-in-cache. WebLogic Server usa una caché de instancias para mejorar el rendimiento de los EJBs stateful session. El mecanismo de cache almacena instancias activas de EJBs en memoria para que estén disponibles inmediatamente para las peticiones de los clientes.
El gráfico siguiente se muestra el cache de WebLogic Server y los procesos en los cuáles los EJBs stateful entran en la caché y/o la dejan. Es importante destacar, que no existen instancias de stateful session EJB en WebLogic Server en tiempo de arranque.
Antes de que un cliente empiece a acceder a un bean stateful session, crea una nueva instancia de bean para usar durante su sesión con el bean. Mientras la sesión está activa, la instancia se cachea en memoria y cuando la sesión se acaba, la instancia se destruye. El proceso de activación o Activation es la transferencia de una instancia EJB de almacenamiento secundario a memoria, así como passivation es la transferencia de una instancia EJB de memoria a almacenamiento secundario. Ajustando max-beans-in-cache a un valor muy alto, se consume mucha memoria de forma innecesariamente. El contenedor EJB realiza una passivation cuando la caché
Pág. 33 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011 se llena y cuando el objeto de sesión EJB se necesita de nuevo, el bean se activa mediante un contenedor.
¿Qué pasa cuando la cache se llena? Weblogic Server ofrece dos opciones ante esta situación con el fin de liberar memoría en la caché: Destruir EJBs que hace tiempo que no se usan. Aplicar el mecanismo de Passivatization a EJBs en concreto. Ambas acciones tienen como efecto la reducción del número de EJBs que están consumiendo parte de la caché de forma que un slot quede disponible para otro EJB.
Configuración del tamaño de la cache Determinar el tamaño apropiado de caché para el conjunto de beans de tipo stateful session requiere un trabajo de análisis y un amplio conocimiento del aplicativo. El tamaño de la caché debe depender de la cantidad de memoria disponible para el consumo de EJBs. Y hay que tener en cuanta que cuando todos los EJBs están activos simultáneamente en el sistema, su consumo total de memoria nunca debe exceder la cantidad disponible en el heap de la JVM. Para ello, hay que calcular el tamaño aproximado de cada tipo EJB, el número de tipos EJB desplegados en un sistema y la cantidad total en el heap. A esta cantidad se le debe sumar coste adicional y fijo de entre dos o tres MB de RAM para administración. Finalmente, hay que considerar la opción del clustering como solución de cache remota, ya que la replicación de EJBs se encargará de usar el espacio libre de otros servidores.
Idle Timeout and Eligibility WLS hace barridos constantes de caché porque intentan optimizar el rendimiento, de forma que asegure que la cantidad de caché tomada por los EJBs se encuentra en un nivel apropiado por lo que es importante el rendimiento general del sistema que esta operación sea eficiente en el servidor. Si un EJB excede su valor especificado en el archivo METAINF\weblogic-ejb-jar.xml file, puede ser destruído por Weblogic Server. Pero debemos tener en cuenta que un EJB es elegible para passivation si no ha excedido su valor de , no está participando en una transacción, y no se encuentra ejecutando un método. Por tanto, sólo ciertos tipos de EJBs son elegibles para el proceso de passivation.
Pág. 34 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
Políticas para la gestión de la cache Cuando se activa la política LRU para la gestión de la cache, el contenedor realiza las siguientes operaciones: •
Envía instancias a disco, tan pronto como una instancia se vuelve inactiva por idle-timeout-seconds, independientemente del valor de max-beans-in-cache. También realiza esta operación si se alcanza max-beans-in-cache, aunque idletimeout-seconds no haya expirado
•
Elimina una instancia en modo passivated de disco después de que se vuelva inactiva por idle-timeout-seconds después de la passivation. Esto se le denomina eliminación perezosa o lazy remove.
•
Elimina una instancia de la caché cuando idle-timeout-seconds expira y no se pasa a disco. A esto se le denomina eager remove. Un eager remove asegura que una instancia inactiva no consume memoria o recursos de disco.
•
Manda instancias a disco cuando se alcanza max-beans-in-cache, aunque idletimeout-seconds no haya expirado.
Configuración de la cache para EJB stateful session No hay instancias de EJBs de tipo stateful session en tiempo de arranque de Weblogic Server. Cuando los clientes buscan y obtienen referencias a beans individuales, Weblogic Server inicializa nuevas instancias de la clase EJB y las almacena en caché. Si se alcanza max-beans-in-cache y hay EJBs en caché que no se están usando, Weblogic Server provoca que se pase a pasivo algunos de esos beans aunque no hayan alcanzado su límite idle-timeout-seconds. Cuando un EJB se convierte en elegible para el proceso de passivation, no significa que Weblogic Server provoca que se arranque el proceso de passivation para el bean immediatamente. El proceso de passivation se produce sólo cuando el EJB es elegible para ello y hay presión por falta de recursos en el servidor, o bien Weblogic Server lleva a cabo un mantenimiento regular de caché. Se puede especificar ese mecanismo de forma explícita para EJBs que hayan alcanzado idle-timeout-seconds modificando el elemento cache-type del archivo weblogic-ejb-jar.xml. • •
Especificar LRU como política, si se requiere una proceso de passivation más agresiva de EJBs. Especificar NRU cuando haya presión de memoria en caché y se quieran mantener en memoria los beans que el cliente utilice más frecuentemente.
Cuando escasean los recursos y la caché necesita memoria, Weblogic Server examina los EJBs que están acercándose a su límite de max-beans-in-cache. De esos beans,
Pág. 35 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011 Weblogic Server elimina las instancias EJBs que no hayan sido usadas durante idletimeout-seconds de la caché, en lugar de moverlos a disco. Una vez que una instancia de un EJB stateful session pasa a disco, un cliente tiene idle-timeout-seconds para utilizar la instancia EJB. Pasado este tiempo, WLS lo elimina de disco. Alternativamente, se puede ajustar el valor de los descriptores maxbeans- in-cache y el idle-timeout-seconds de un EJB de tipo stateful sesión, tal como se muestra a continuación: * @ejbgen:session max-beans-in-cache="1000" idletimeoutseconds="60" * ejb-name = "ShoppingCartBean" ShoppingCartBean 1000 60 ...
Beans de entidad (Entity beans) Cuando decimos que un EJB es persistente, nos referimos a que los datos del EJB persistirán o existirán esté o no el EJB en memoria. La persistencia de un EJB puede ser implementada de varias formas. Por ejemplo, el objeto puede ser almacenado en una base de datos relacional, en un archivo o colocado en otro medio. Cuando se crea un entity EJB, el dato que representa el EJB se coloca en un almacenamiento persistente, por ejemplo, con un insert en una base de datos, y una copia del dato se almacena en memoria como parte del EJB ó como una agregación de objetos que gestiona el EJB. Cada vez que los atributos de los objetos en memoria se modifican, sus homólogos persistentes se actualizan automáticamente. Ya que el valor del EJB se almacena de manera persistente, múltiples clientes pueden acceder a los mismos datos en el mismo instanta. Los contenedores pueden implementar dos peticiones de acceso por parte de los clientes al mismo dato de distintas formas. Por ejemplo, el contenedor puede serializar el acceso a los datos a través de un single object, permitiendo sólo a un single client el uso del objeto al mismo tiempo, o puede crear dos copias del dato persistente donde el contenedor sería responsable de coordinar modificaciones concurrentes de los datos. Dos clientes que usan la misma entidad EJB no es lo mismo que dos clientes que usan el mismo session EJB. De hecho, dos clientes que usan el mismo entity EJB significa que ambos tienen acceso a los mismos datos persistentes. El contenedor puede crear una instancia o múltiples para gestionar cómo múltiples clientes
Pág. 36 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011 “comparten” los mismos datos. Este es un concepto un poco complicado que Weblogic Server aplica de múltiples formas.
Configuración de la cache y el pool para EJB de tipo Entity Definir los tags en el archivo weblogic-ejb-jar.xml para un entity bean es muy similar a como se hace con el resto de tipos de beans. Se debe incluir un tag para albergar un tag , ya que tiene el mismo significado que en los stateful session bean, controla el número de beans en el pool que se permiten en memoria al mismo tiempo. El tag es igual que en los stateless session beans, tal como se muestr a continuación: OrderBean 15 5 1000 60
Caches combinadas para EJBs Entity El cacheo a nivel de aplicaciones tiene las siguientes ventajas: •
Reduce el número de cacheos de entity bean y por tanto el esfuerzo de configurar la caché.
•
Hace un mejor uso de la memoria y heap space de la JVM al reducir la fragmentación. Por ejemplo, si un EJB en particular, experimenta un pico de actividad, puede usar toda la memoria disponible de caché, mientras que se paginan otros EJBs. Si dos EJBs usan cachés diferentes, cuando una caché se llene, el contenedor no puede paginar EJBs en el caché del otro bean, y el resultado es un gasto de memoria.
•
Proporciona una mejor escalabilidad.
Para usarla, necesitamos definir una entidad de caché de nivel de aplicación que se define en el fichero weblogic-application.xml: appLevelCache1 1000 MultiVersion ...
Pág. 37 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011 Además de una referencia a una entidad de caché de nivel de aplicación definida en el fichero weblogic-ejb-jar.xml: CorporateAddressRO appLevelCache1 600 true ReadOnly 20 ... Cada valor del elemento en weblogic-ejb-jar.xml debe coincidir con el valor de un elemento en weblogic-application.xml.
Cache y transacciones Si hacemos un llamada del contenedor para invocar al método ejbLoad() por cada transacción simple, podemos encontrarnos con un problema de lentitud en el procesamiento de éstas. Aunque esta técnica se realiza para prevenir problemas de sincronización, En algunos casos, es posible cambiar este comportamiento para optimizar el procesamiento. Para hacerlo, hay que poner el tag en el archivo weblogic-ejb-jar.xml.
Es importante destacar que si más de un cliente está accediendo a los datos al mismo tiempo, puede haber pérdida de datos con se usa esta técnica y además no estará disponible en entornos basados en clústeres. Veamos el gráfico anterior:
Pág. 38 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011 1. Un cliente llama a un método que genera una transacción. 2. Comienza una transacción. 3. Si cache-between-transactions es false, la llamada del contenedor ejbLoad() antes de ejecutar el método, de lo contrario el método se ejecuta. 4. Cuando la transacción se confirma, commit, se produce la llamada a ejbStore(). AccountEJB 1000 True AccountEJB
Estrategias de concurrencia para Entity Beans Dado que múltiples clientes pueden acceder a un mismo entity bean de forma concurrente, los servidores EJB deben dar soporte a niveles de concurrencia. Weblogic Server soporta cuatro estrategias de concurrencia: Exclusive Database, por defecto ReadOnly Optimistic En momento que se tiene un servidor donde más de una hebra puede acceder a un recurso protegido, como datos, el servidor necesita soporte a niveles de concurrencia para proteger los recursos y a los clientes que acceden a los mismos. En este caso de entity beans, los recursos serán típicamente datos. Se puede dar una situación en que más de un cliente esté accediendo a la misma primary key a través del entity bean, y por tanto al mismo dato. Es lo que se llama un „dirty read.‟ Finalmente, recordar que la elección de la estrategia adecuada para una aplicación puede mejorar el rendimiento.
Estrategias de concurrencia • Exclusive Establece un bloqueo exclusivo en instancias cacheadas de entity EJB cuando el bean está asocidado a una transacción. Bloqueaa otras peticiones para la instancia EJB hasta que la transacción se completa. • Database Aplaza el bloqueo de peticiones para un entity para la base de datos. Distribuye una instancia separada de entity bean y permitir a la base de datos manejar el bloqueo y el cacheo.
Pág. 39 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011 • ReadOnly Activa un nueva instancia para cada transacción, así las peticiones se procesan de forma paralela para los entity beans. Configura Weblogic Server para comprobar mediante un timeout de lectura y si los datos de caché son más antiguaos Invalida los read-only beans cuando se llama al método invalidate() y envia un mensaje multicast a través del cluster para invalidar las copias cacheadas en el resto de nodos. • Optimistic Los bloqueos no se mantienen en el contenedor EJB ni en la base de datos durante una transacción. El contenedor EJB verifica que no ha cambiado ningún dato actualizado por la transacción antes de la confirmación de la misma, commit, y el contenedor EJB deshace la transacción si se produjo algún cambio.
La estrategia de concurrencia “exclusive” era la que estaba por defecto en WebLogic Server en versiones anteriores como, 4.5.1 y 5.1. Y permitía un acceso fiable a datos EJB y evita llamadas innecesarios a ejbLoad() para refrescar los campos persistentes de la instancia EJB. Sin embargo, el bloqueo exclusivo no proporciona el mejor modelo para acceso concurrente a datos por parte de los EJBs. Una vez que un cliente ha bloqueado una instancia EJB, otros clientes se bloquean si intentan acceder a los campos persistentes. El contenedor EJB en WebLogic Server puede usar el mecanismo de bloqueo exclusivo para instancias de entity EJB. Cuando los clientes seleccionan un EJB o un método EJB en una transacción, WebLogic Server bloquea la instancia EJB durante la transacción. Otros clientes que soliciten el mismo EJB o método se bloquearán hasta que se complete la transacción actual. La estrategia de concurrencia “Database” es la estrategia de concurrencia por defecto. Con el mecanismo de bloqueo de base de datos, el contenedor EJB puede continuar cacheando instancias de clases de entity EJB. Sin embargo, el contenedor no cachea el estado intermedio de una instancia EJB entre transacciones. En su lugar, WebLogic Server llama a ejbLoad() para cada instancia al principio de una transacción para obtener los últimos datos de EJB. La petición para confirmar los daots se pasa posteriormente a la base de datos. Y por tanto, ésta maneja toda la gestión de bloqueos y la detección de deadlock para los datos de EJBs.
Pág. 40 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011 Se puede especificar cacheo de read-only entity bean a nivel de aplicación o de componente. Para habilitar el cacheo de read-only en entity bean es necesario: • • • •
Especificar la opción ReadOnly en la opción del descriptor de despliegue concurrency-strategy para cada archivo JAR ó EAR. Especificar el elemento concurrency-strategy para cachés de nivel de aplicaciones (EARS) en el archivo weblogic-application.xml. Especificar el elemento concurrency-strategy para cachés de nivel de componente (JARS) en el archivo weblogic-ejb-jar.xml. Invalidar un read-only entity bean mediante la llamada al método invalidate() de la interfaz CachingHome ó CachingLocalHome:
public interface CachingHome { public void invalidate(Object pk) throws RemoteException; public void invalidate (Collection pks) throws RemoteException; public void invalidateAll() throws RemoteException; } Cuando se llama al método invalidate(), los read-only entity beans se invalidan en el servidor local, y se envía un mensaje multicast al resto de servidores del cluster para invalidar sus copias en caché. La siguiente llamada a un read-only de tipo entity bean invalidado causa una llamada a ejbLoad(). Finalmente, la estrategia de concurrencia “Optimistic” no mantiene ningún bloqueo en el contenedor EJB ni la base de datos mientras la transacción está en proceso. Cuando se especifica esta opción, el contenedor EJB se asegura que los datos que se actualizan con la transacción no han cambiado. Realiza un “smart update” comprobando los campos antes del commit de la transacción. PurchaseOrderBean Exclusive | Database | | Optimistic | ReadOnly
Entity Bean Bulk Updates Existen situaciones donde múltiples instancias del mismo bean de entidad de tipo CMP cambian en una misma transacción. Si el contenedor EJB ejecuta sentencias SQL/DML para todas las instancias de beans CMP, las actualizaciones pueden convertirse en un cuello de botella en cuestiones de rendimiento. Las operaciones por lotes o en batch en actualizaciones de EJBs solucionan este problema mediante la actualización de múltiples entradas en una tabla de la base de datos en un batch de sentencias SQL/DML. Con ello se mejora el rendimiento haciendo múltiples inserts, deletes o updates para los beans CMP en un envío a la base de datos.
Pág. 41 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011 Para permitir inserts, updates o deletes en modo batch en una base de datos, es necesario habilitar el elemento enable-batch-operations del archivo weblogic-cmpjar.xml poniendolo al valor true tal como se muestra a continuación: True
Directiva include-updates De acuerdo con la especificación EJB, las actualizaciones hechas por una transacción deben ser reflejadas en los resultados de los query-finders y ejbSelects emitidos durante la transacción. Este requerimiento puede disminuir el rendimiento ya que realmente se procede a limpiar el caché antes de ejecutar la query. Para ello es necesario cambiar el valor del elemento include-updates de true a false en el archivo weblogic-cmp-jar.xml. La decisión de deshabilitar cache flushing depende de si el rendimiento es más importante que ver la mayor cantidad de datos. Poniendo include-updates a False obtenemos el mejor rendimiento pero las actualizaciones de la transacción actual no se reflejan en la query. findGoldCustomer ... ... True
Cacheo de relaciones (relationship caching) El cacheo de relaciones o relationship caching mejora el rendimiento de los beans de tipo entidad al cargar en caché los beans relacionados con el primero, evitando así realizar múltiples consultas utilizando una join query para los mismos. Veamos algunas características: •
En entity relationships, se usan múltiples queries para cargar entity beans relacionados.
• El rendimiento se puede mejorar cargando todos los beans relacionados en caché • Esto se puede conseguir activando relationship caching en weblogic-cmpjar.xml. • Relationship caching usa joins multinivel para cargar múltiples beans usando una sentencia SQL.
Pág. 42 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
Configuración del cacheo de relaciones Veamos un ejemplo de configuración del cacheo de relaciones: … cacheMoreBeans accounts acct_group address addr_group phone phone_group … No hay limitación en el número de caching-elements a especificar. Sin embargo, si se disponen muchos niveles, se podría obtener un impacto negativo en el rendimiento de la transacción.
Campos de grupos Un grupo especifica un conjunto de atributos persistentes de un bean de entidad. Un campo de grupo o field-group representa un subconjunto de los campos CMP y CMR de un bean. Se pueden poner campos relacionados en un bean en grupos que van en memoria como una unidad. Igualemnte, se puede asociar un grupo con una query o relación, de forma que cuando se carga un bean como resultado de ejecutar una query o fruto de una relación, sólo se cargan los campos mencionados en el grupo. MedicalBean medical-data insurance doctors El mecanismo de eager loading es una forma de especificar qué datos se cargan y si se cachean en la duración de una transacción. Si un método de tipo finder se usa en una transacción, y en una transaction posterior el bean devuelto por el método finder vuelve a ser accedido, usando por ejemplo un método get, el campo accedido se carga de nuevo, ya que los datos podrían haber cambiado.
Pág. 43 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011 Si está habilitado el cacheo entre transacciones, entonces se usará el mecanismo eager loading la primera vez para cachear los datos, pero posteriormente se usarán los datos almacenados en caché. Hay que verificar que finders-load-bean es true, o bien no indicarlo. Cuando está a false, los query methods cargarán siempre los valores de las primary keys del bean devuelto por la query.
Container-Managed Transactions (CMT) Una forma de usar transacciones en EJBs es delegando al contenedor todo el manejo de éstas. A esto se le conoce como container-managed transactions ó CMT. Con CMT, se puede deciridr qué métodos deben tener una transacción activa durante su ejecución y el contenedor comenzará la transacción antes de llamar al método y hacer commit o rollback de la transacción una vez completado el método.
El gráfico muestra el proceso: • El cliente hace la invocación. • El contenedor empieza la transacción como parte del proceso de pre-invocación. • Se invoca el bean. • Se hace rollback o commit de la transacción como parte del proceso de postinvocación.
Tag Cuando se indica el tag como container, el tag se usa para indicar el tipo de comportamiento de la transacción que debe existir para los diferentes métodos del bean. Este tag contiene, a su vez, los tags y . El primero indica el comportamiento que debe adoptar el contenedor cuando se llama a estos métodos. El segundo especifica uno o más métodos de un EJB. ... JspSession * Required ... Una revisión rápida de la sintaxis del tag :
Pág. 44 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
o Especifica el nombre del EJB que aloja el método. o Es opcional y especifica la interfaz donde se ubican los métodos. El valor puede ser Home, Remote, Local ó LocalHome. Si se omite, los métodos de todas las interfaces deben especificarse. o Es el nombre de un método o *, que indica todos los métodos. o Es opcional y contiene una lista de tags . Si múltiples métodos tienen el mismo nombre con diferentes parámetros, se puede especificar el prototipo del método. o No se puede usar con *.
Valores para el tag El tag puede tener uno de estos seis valores: Never: Especifica que el EJB no puede ser invocado en el contexto de una transacción. NotSupported: Provoca que las transacciones se suspendan durante la ejecución de EJBs. Supports: Implica que el EJB se incluirá en cualquier transacción iniciada por el cliente. Required: Fuerza al EJB a ejecutarse en una transacción iniciada por el cliente o el contenedor. RequiresNew: Fuerza al EJB a ejecutarse en una nueva transacción iniciada por el contenedor. Mandatory: Obliga al cliente a pasar una transacción global al EJB. Cada valor indica el comportamiento que el contenedor debe adoptar cuando los métodos que generan, o estén expuestos a, transacciones son invocados. Cada atributo indica qué hacer con una transacción iniciada por un cliente y si debe iniciarse una nueva transacción. Estos seis atributos de transacción generan un gran número de escenarios posibles. Hay que tener en cuenta que un EJB puede ser cliente de otro EJB, lo cual multiplica las posibilidades.
Nivel de aislamiento Es posible ajustar el nivel de asilamiento con el tag . Este tag contiene dos cosas: el nivel de aislamiento y los métodos que aplican en este nivel. Este tag puede repetirse tantas veces como sea necesario.
Pág. 45 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
Los cuatro niveles de aislamiento disponibles son: •
• • •
TRANSACTION_READ_UNCOMMITTED: Operaciones dirty reads, nonrepeatable reads, y phantom reads están permitidas. Este es el nivel de aislamiento más permisivo. TRANSACTION_READ_COMMITTED: No se permiten dirty reads. Sí se permiten non-repeatable reads y phantom reads. TRANSACTION_REPEATABLE_READ: No se permiten dirty reads ni nonrepeatable reads. Si se permiten phantom reads. TRANSACTION_SERIALIZABLE: No se permiten dirty reads, non-repeatable reads o phantom reads. Este es el nivel de aislamiento más restrictivo.
… TRANSACTION_READ_UNCOMMITTED dogEJB * …
Consideraciones de diseño • • • •
La configuración de las transacciones pueden tener un gran impacto en el rendimiento. Muchas transacciones muy atómicas generan un tráfico excesivo de transacciones y pueden provocar la satuación de los resource managers. Transacciones que actualizan mutitud de registros pueden bloquear a otros clientes accediendo a los mismos recursos. Como buena práctica, puede tratarse de crear un bean de sesión que a través del patrón fachada o facade envuelva o agrupe múltiples invocaciones a métodos EJB para eliminar la acreación de múltiples transacciones.
Todas las consideraciones de diseño están orientadas a la reducción del número de transacciones y asegurar que el alcance de cada transacción es a través de la menor cantidad de recursos posibles. Finalmente, es importante asegurarse de limitar las transacciones, por ejemplo, en una petición Web, y no permitir que que las transacciones abarquen peticiones que tengan relación con el control o el flujo Web.
Timeout de transacciones Veamos ahora las características del mecanismo de timeout dentro del control transaccional: • Evitan que los recursos permanezcan innecesariamente ocupados por períodos largos, asegurando que la transacción nunca incluye la entrada de usuario. • Aseguran que las transacciones provocan bloqueos de filas en la base de datos del menor tiempo posible.
Pág. 46 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
Para configurar el timeout de transacción es necesario modificar el fichero weblogicejb-jar.xml, tal como se muestra a continuación: 20
Pág. 47 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
Best Pratices para clustering El Clustering es un grupo de WebLogic Servers que actúan de manera coordinada para proporcionar a los clientes un acceso a los servicios que ofrecen los servidores que forman el cluster. Los servicios que proporciona un cluster pueden ser un super conjunto de los servicios que proporciona uno de los servidores del cluster. Sin embargo, es una buena práctica que todos los servidores que pertenecen a un mismo cluster den los mismos servicios. De cara al cliente, el cluster aparece como una única instancia, ya sea el cliente un cliente Web ó una aplicación Java. Al replicar los servicios proporcionados por un servidor, este tipo de arquitecturas construyen sistemas escalables y con tolerancia a fallos. La alta disponibilidad se consigue mediante la replicación de los servicios, así cuando un servicio falla, un segundo servicio puede reanudar por donde se quedó el primero. La escalabilidad se consigue mediante el balanceo de las peticiones que llegan a todos los servidores del cluster. Por ejemplo, si hay cuatro servidores en un cluster y cuatro peticiones, se pueden balancear las peticiones de forma que cada servidor reciba una de ellas. Un cluster estára formado por diversos servidores de un mismo dominio, aunque no es obligatorio que todos los servidores pertenezcan a una cluster. Por regla general, éstos están precedidos de frontales, bien balanceadores bien servidores proxy, que se encargan de dirigir la carga de las peticiones a todos los elementos del clúster como un todo, y en ocasiones limitando el acceso de forma directa a un componente en concreto.
Balanceo de carg y failover Balanceo de carga Para conseguir una buena escalabilidad, cada servidor de un cluster debe usarse de forma que se maximice su capacidad de uso. Dicho de otra manera, que sea usado de forma completamente y de forma independiente y transparente al número de componentes que lo formen. A este conjunto de técnicas se recogen bajo el balanceo de carga. El desafío de implementar el balanceo de carga es balancear de una forma simple y efectiva. Si todos los servidores del cluster tienen recursos equivalentes y ofrecen los mismos servicios, un algoritmo simple de balanceo de carga que no requiere conocimiento de los servidores valdrá. Si por el contrario, los servidores varían en potencia o en el tipo de servicios, hay que especificar un algoritmo que tenga en cuenta estas diferencias. El proxy plug-in de Weblogic Server mantiene una lista de instancias WebLogic Server que alojan un elemento clusterizado, como un servlet o un JSP, y reenvía peticiones HTTP a esas instancias utilizando la estrategia round-robin.
Pág. 48 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011 Los clusters que usan un balanceo de carga hardware pueden usar cualquier algoritmo de balanceo de carga soportado por el hardware.
Failover Las instancias WebLogic Server son capaces de detectan fallos en el resto de los miembros del clúster gracias a una monitorización activa de cada uno de los elementos que lo forman. Como ejemplo de esta monitorización, podemos comentar la monitorización de las conexiones a través de sockets entre los elementos del cluster. Si un servidor se conecta a uno de sus iguales en el clúster y comienza a transmitir datos a través de un socket, un cierre inesperado de éste puede causar que dicho servidor quede marcado en estado FAILED y sus servicios asociados se eliminen del árbol JNDI del clúster.
Arquitectura básica de un clúster La arquitectura básica recomendada de un cluster de Weblogic Server combina todos los niveles de las aplicaciones web, es decir, HTTP estático, capa de presentación y capa de negocio, en un mismo clúster. La arquitectura básica tiene algunas ventajas claras: Fácil administración, ya que un clúster simple al alojar todos los elementos, páginas HTTP estáticas, servlets y EJBs, se pueden configurar, desplegar y/o eliminar objetos y aplicaciones web de forma atómica, usando, por ejemplo, la consola de administración. Balanceo de carga flexible, el uso de balanceo de carga hardware en un cluster WebLogic Server permite el uso de políticas avanzadas de balanceo de carga para el acceso a contenido tanto dinámico como estático. Seguridad robusta, ya que al poner un firewall en el hardware de balanceo de carga, permite crear una “zona desmilitarizada” o DMZ para las aplicaciones web con un mínimo de políticas de seguridad respesto a los firewalls. Mediante una arquitectura de niveles combinada como la recomendada, satisfacen las necesidades de la gran mayoría de aplicaciones web.
se
Arquictura multi capa de un clúster La arquitectura multi capa o multi-tier recomendienda el uso de almenos dos clusters de WebLogic Server separados. El primero de ellos, para servir contenido estático y dinámico HTTP y el segundo para servir objetos de tipo EJBs en clúster. La arquitectura multi capa proporciona las siguientes ventajas: Balanceo de carga en métodos EJBs, ya que mediante el alojo de servlets y EJBs en clusters separados, las llamadas a métodos desde los servlets a los EJBs se pueden balancear en múltiples servidores.
Pág. 49 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
Mejor balanceo de carga en el servidor, ya que al separar los niveles de presentación y de negocio, donde residen los objetos en cluster, se proporciona más opciones para distribuir la carga de las aplicaciones. Por ejemplo, si la aplicación accede a contenido HTTP y servlets más frecuentemente que a contenido servido a través de EJBs, se pueden usar una mayor cantidad de instancias de WebLogic Server en el nivel de presentación del cluster minimizando el número de servidores que alojan los EJBs. Disponibilidad más alta, ya que mediante el uso de instanicas de WebLogic Server adicionales, la arquitectura multi capa tiene menos puntos de fallo que la arquitectura anterior. Por ejemplo, si un Weblogic Server que alberga un EJB en clúster falla, la capa de presentación podrá reencaminar la petición a otro miembro del cluster, y por tanto continuar de forma transparente. Mayor seguridad, ya que al separar las capas de presentación y negocio en dos clústeres independientes, se pueden establecer políticas de seguridad y de firewalling para cada una de las dos zonas, creando un DMZ en la zona de presentación y una zona segura en la capa de negocio.
Clustering para entornos Metropolitan Area Network (MAN) Los recursos en las redes de tipo MAN suelen esta en diferentes localización, pero lo suficientemente cerca como para que la latencia de este tipo de redes sea un problema a tener en cuenta. Este tipo de redes suelen proveer servicios de alta velocidad y baja latencia, por lo que los clústeres de Weblogic Server se pueden instalar sin mayores problemas en este tipo de redes. Para mejorar el failover de Weblogic Server en redes MAN, éste permite un mecanismo basado en memoria capaz de trabajar con dos clúster distantes. Esto es posible gracias a la replicación síncrona de un clúster a otro soportando por la baja latencia de la red. Este factor debe comprobarse y asegurarse, ya que es clave en el correcto funcionamiento del sistema.
Balanceadores de carga Básicamente existen de dos tipos, hardware como los fabricados por Cisco, Foundry Networks yBig IP, y los software, como Apache, Netscape, MS IIS o WebLogic Server a través de proxy plug-ins.
Consideración para balanceadores de carga por hardware A continuación se enumeran algunas consideraciones a tener en cuenta durante la configuración de Weblogic Server sobre balanceadores de carga hardware. Passive cookie El mecanismo de persistencia a través de passive cookie permite a Weblogic Server crear una cookie que contiene un parámetro de sesión que a través del balanceador de carga llega al cliente.
Pág. 50 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011 En el caso de uso de balanceadores de tipo hardware es obligatorio la configuración de este mecanismo para evitar que se sobreescriba dicha cookie que es usada por Weblogic Server para comprobar y seguir la correspondencia de los servidores primerio y secundario de la replicación en memoria. Esta cookie posee el siguiente formato: • •
Una cadena de texto con el valor de la session ID más un byte como carácter delimitador. Una cadena de texto de una longitud de diez para almacenar la pareja de valores de primario y secundario.
Active cookie El mecanismo de persistencia basado en active cookies está soportado por Weblogic Server siempre y cuando dicho mecanismo asegure que las cookies no serán sobreescritas o modificadas. En es caso, no es necesario ninguna configuración extra además de la indicada en el caso del mecanismo de pasive cookies. Persistencia SSL En el caso de SSL, es el balanceador el responsable de encriptar y desencriptar la información que circula entre los clientes y el clúster a través de una cookie en texto plano que mantiene la correspondencia entre el cliente y el servidor dentro del clúster.
Replicación de sesión Componentes Web como servlets o páginas JSP mantienen datos de clientes en instancias del objeto HttpSession. Por tanto, si deseamos tener la capacidad de alta disponibilidad, esta información tiene que ser compartida por todos los nodos del clúster. Para ello las instancias de HttpSession puede ser replicada a través de la replicación en memoria o in-memory replication, persistencia en file system o persistencia en base de datos
Replicación basada en memoría En el caso de la replicación basada en memoría o in-memory replication, los objetos replicados no son accesibles por la totalidad los servidores del cluster. Sin embargo, cuando se crea un objeto, objeto primario, se crea una imagen de backup en otro servidor del clúster, llamado objeto secundario. En el caso de perdida del primero, el secundario es promocionado al primario para el resto de futuras peticiones. De la misma forma, se busca un nuevo servidor, capaz de albergar al nuevo objeto secundario que es creado a partir del nuevo primario. De esta forma, se reduce los canals de comunicación necesarios para la replicación de un objeto realizándose entre parejas de servidores y no a través del clúster completo.
Pág. 51 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
Persistencía basada en JDBC En el caso de la replicación basada en persistencia JDBC, es necesaria una base de datos que almacene la información de los objetos de tipo HttpSession. Una vez configurado, cada una de los managed server que forman el cluster usarán la misma configuración para crear el pool de conexiones que le permita acceder a la información compartida por la base de datos. En esta situación, si por ejemplo, un servlet crea un objeto de sesión, éste almacena la información en la base de datos. Las siguientes peticiones del cliente, sea al miembro del clúster que sea, podrán manejarse de igual forma, ya que todos tiene acceso a la información almancenada. Este mecanismo posee una mejor capacidad de failover dado que cualquier servidor puede resolver y atender cualquier petición desde los clientes, pero por el contrario, tiene una reducción significativa de rendimiento al tener que sincronizar cualquier cambio con la base de datos.
Persistencía basada en file system compartido Finalmente, la persistencia de sesión basada en file system parte de la capacidad de éste de ser compartido a nivel de acceso por todos los miembros del clúster. En esta caso, cuando un servlet crea un instancia de HttpSession, Weblogic Server escribe los datos correspondientes en una datastore vinculado a un file system compartido. Al igual que en el caso anterior, posee buenas características de failover pero también presenta problemas de rendimiento, especialmente en la sincronización de las escrituras y lectura de todos los miembros del clúster.
Configuración de los tipos de replicación Replicación de tipo In-memory: replicated replicated_if_clustered Replicación de tipo File System: file Directory Path
Pág. 52 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
Replicación de tipo JDBC: jdbc Data Source Name
Pág. 53 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
Best practices para Work Managers Weblogic Server usa un mecanismo de pool de hebras único que se adapta de manera automática para maximizar la productividad del sistema. A este proceso se le conoce como mecanismo de self-tuning. En este proceso, los queue monitor evalúan la carga del sistema a través del tiempo y así como información histórica para ajustar el valor del número de hebras necesario, incrementando o decrementando según sea necesario de una forma totalmente interna al pool de hebras. Weblogic Server prioriza la carga de trabajo recibida basandose en las reglas definidas por los adminsitradores y en base a sus métricas de rendimiento internas, como el tiempo empleado en ejecutar una petición o el ratio de entrada y salida de las petición al pool de hebras. De esta forma se hace más sencillo para los administradores ajustar la cantidad de recursos necesarios y se reduce, en general, las tareas de monitorización y ajuste de colas configuradas por ellos.
Default Work Manager Weblogic Server, por defecto, usa una única cola de ejecución basada en prioridades donde todas las aplicaciones desplegadas tienen la misma prioridad de ejecución. A este tipo de reparto de prioridades se le conoce como reparto equitativo o fair share. Este work manager por defecto, llamado default work manager, puede reconfigurarse creando y configurando un work manager global también llamado defualt. En él, el tamaño del pool de hebras puede ser configurado tanto es su límite máximo como en su límite mínimo.
Clases de tipo Request Los adminsitradores puede determiner una serie de guías y asociarla a una o más aplicaciones o a un componente en particular. Weblogic Server usará estas guías para realizar la asignación del trabajo pendiente. Las clases de tipo Request permite planificar el trabajo en base a la prioridad. Hay que tener en cuenta que básicamente existen dos componentes en un work manager: las clases request y las restricciones (constraints). Pueden usarse cualquier de ellas para controlar el rendimiento de una aplicación referenciando el nombre del componente en descriptor de despliegue. O bien puede crear un work manager que encapsule estos componentes y referenciar a éste también en el descriptor de despliegue.
Pág. 54 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
Clases de tipo Fair Share Request Tal como hemos comentando en los work managers configurados como fair share, la gestión se basa en prioridades. Y aunque todas las aplicaciones tiene por defecto la misma prioridad, ésta puede cambiarse de forma, que una aplicación con un valor para fair share de 1000, será la que tenga la prioridad mas alta de todas las posibles. Vemoas un ejemplo, asumimos que existen tres modulos en ejecución. El work manager para el modulo A indicar una fair-share-request-class de 90, mientras que el módulo B lo hace de 10. En caso de producirse la suficiente demanda sobre el servidor que los conteniene a ambos, Weblogic Server repartirá los recursos en uso en un 90 y un 10% respectivamente para los modulo A y B. fair-share-request-class> high_priority 90 low_priority 10
Clases de tipo Response Time Request Aunque el objetivo de tiempo de respuesta no se aplica a las peticiones de forma individual, Weblogic Server reliza los cálculos necesarios para asegurar que el tiempo de respuesta tolerable mediante la subtracción del tiempo empleado por la hebra del tiepo total de respuesta. De esta forma, Weblogic Server planifica este tipo de peticiones dentro de la media de espera por petición proporcional al tiempo de espera indicado. Veamos un ejemplo, si Weblogic Server ejecuta dos módulos, A y B, y deseamos un ratio de 1:8 entre ellas, usaremos la siguiente configuración: fast_response_time 1000 slow_response_time 8000
Clases de tipo Context Request Este tipo de clases permite asignar una clases de tipo de request en base a una valor de la petición y/o a una propiedad de un role. Es decir, mapea el contenido con las clase de tipo request que debe ejecutarse.
Pág. 55 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011 simple_context system high_fairshare everyone low_fairshare
Resctricciones (Constraints) Las restricciones definen: El valor máximo y mínimo de hebras que se crear para ejecutar las peticiones. El número total de peticiones que encoladas antes de que Weblogic Server comience a rechazas peticiones. Existen tres tipos de restricciones: max-threads-constraint min-threads-constraint capacity
Resctricción Maximum Threads Esta restricción limita el número máximo de hebras que concurrentemente ejecutan este tipo de petición. Las opciones de configuración son las siguientes: Name: Nombre de la restricción. Count: Número de hebras, por defecto -1. Data Source: Opcionalmente, el nombre de la connection pool de donde se tomará el valor máximo. max_threads 10
Resctricción Minimum Threads Esta restricción limita el número mínimo de hebras que concurrentemente ejecutan este tipo de petición. Las opciones de configuración son las siguientes: Name: Nombre de la restricción. Count: Número de hebras, por defecto -1.
Pág. 56 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011 min_threads 1
Resctricción Capacity Este tipo de restricción permite que el servidor rechace peticiones en caso de que se alcance el límite de capacidad establecido para evitar la sobrecarga del sistema. Las opciones de configuración son las siguientes: Name: Nombre de la restricción. Count: Número de hebras, por defecto -1. my_capacity 50 Es importante destacar, que las peticiones son rechazadas tanto si se alcanza el límite de forma individual como de forma global.
Clases y restricciones de tipo Referencing Un work manager puede definirse mediante la encapsulación de una clase de tipo request y una o más restricciones. Las opciones de configuración son las siguientes: Name: Nombre de la restricción o de la clase. priority_work_manager very_high_priority 1000 min_five_Threads 5
Global-Level Work Managers Este tipo de work managers, como su propio nombre indica, afecta a todos los módulos y aplicaciones desplegadas en el servidor, y pueden crearse tango con la consola de administración como directamente sobre el fichero config.xml.
Pág. 57 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011 HighFairShare mainserver 500 MoreThreads mainserver 20 priority_work_manager mainserver HighFairShare MoreThreads Una vez creado, se debe crear al menos una clase de tipo request o una restricción. A partir de ese momento, el work manager las usará para priorizar la carga de trabajo.
Work Manager a nivel de aplicación Este tipo de work manager, aplican exclusivamente sobre las aplicaciones o modulos a los que se le asocia a través del fichero de despliegue weblogicapplication.xml tal como se indica a continuación: app_max_threads 10 app_min_threads 5 AppScopedWorkManager
Work Managers a nivel de aplicaciones Web Este tipo de work managers está exclusivamente disponibles para aplicaciones de tipo Web a través del fichero de políticas, weblogic.xml. LowPriority LowPriority
Pág. 58 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011 LowFairShare 50 LessThreads 2
Work Manager para Stuck Threads Este tipo de work managers, de tipo Stuck Threads, se configuran para detener el work manager en uso elimando todas las hebras siguiendo la parametrización que se índique, aunque también pueden usarse para prevenir la sobrecarga de los managed servers. Las opciones de configuración son las siguientes: Max Stuck Thread Time, es el número de segundos que una hebra debe trabajar de forma continuada en la misma tarea antes de que el sistema la considere bloqueada o en estado stuck. Stuck Thread Count, es el número de hebras en estado stuck para que el servidor sea transladado al estado FAILED. En el ejemplo siguiente se muestra la configuración para un work manager con 5 hebras en estado stuck mas de 60 segundos. stuckthread_workmanager stuckthread_workmanager 60 5
Colas de ejecución (Execute queues) Retrocompatibilidad Desde la versión 10 de Weblogic Server se prove de la posibilidad de usar la retrocompatibilidad de las colas de ejecución con el fin de facilitar las tareas derivadas de las migraciones desde versiones anteriores. Esta retrocompatibilidad permite que:
Pág. 59 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
los work managers configurados se conviertan a execute queues en tiempo de ejecución por parte del servidor. El número de hebras de una execute queue se base en una restricción o constraint. Y que en caso de que un work manager no implemente alguna restricción, se use la global default execute queue. Para que ello sea posible, es necesario realizar uno de los dos cambios siguientes: •
Usar la opción siguiente en la linea de comando de los servidores: -Dweblogic.Use81StyleExecuteQueues=true
•
Añadir la siguiente cláusula al fichero de configuración config.xml: true
Pág. 60 / 60