Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Servicios TIC
Subdirección de Tecnologías de la Información
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
Revisiones
Nombre Role
Distribución
Pág. 2 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
Índice de Contenidos
Pág. 3 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
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.
Pág. 6 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
o Rendimiento
o Escalabilidad
o Alta disponibilidad
o Balanceo de carga
Pág. 7 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
Pág. 8 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
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.
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:
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.
Arquitectura JDBC
Las aplicaciones que usan JDBC pueden usar uno de los cuatro tipos de drivers
JDBC distintos.
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.
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.
La elección del tipo de driver correcto es tan importante que puede tener una gran
influencia en el rendimiento.
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.
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.
Shrink Frequency
Pág. 12 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
Testeo de conexiones
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 <tabla>.
Row Prefetch
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.
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.
Pág. 13 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
• 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é.
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.
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.
Gestión de transacciones
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.
Connection.setAutoCommit(false)
Niveles 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.
Pág. 16 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
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).
• 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
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
• 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
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.
• 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.
Paging
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.
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
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.
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.
Pág. 21 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
Cuotas JMS
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.
Pág. 22 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
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.
Umbrales o threshold
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.
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.
Gestión de expirados
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:
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.
Para ello, se puede configurar un servidor JMS para explorar activamente los
mensajes expirados de los diferentes destinos.
• Hay que diferenciar entre los acuses de recibo o acknowledgments JMS y las
operaciones de commits.
Pág. 25 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
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.
• Habilita una entrega rápida y fiable de mensajes en las aplicaciones que corren
en WebLogic Server
Intervalo de Ventana
Un agente emisor de mensajes esperará para reenviar el mensaje de tipo batch hasta
que:
Pág. 26 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
Tamaño de Ventana
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
http://java.sun.com/products/ejb/index.html.
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
EJBFiles.class
\relative\path\of\package\name\EJBFiles.class
\META-INF\ejb-jar.xml
\META-INF\weblogic-ejb-jar.xml
\META-INF\weblogic-cmp-rdbms-jar.xml
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.
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-beans-
in-free-pool en el fichero weblogic-ejb-jar.xml. Por defecto, este valor es 0.
Si todas las instancias de una clase EJB están activas y se alcanza el max-beans-in-
free-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.
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
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.
<weblogic-enterprise-bean>
<ejb-name>InsuranceQuoteBean</ejb-name>
<stateless-session-descriptor>
<pool>
<max-beans-in-free-pool>15</max-beans-in-freepool>
<initial-beans-in-free-pool>5</initial-beans-infree-
pool>
</pool>
</stateless-session-descriptor>
...
</weblogic-enterprise-bean>
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
En este ámbito, los MDBs son EJBs especiales encargados de recibir los mensajes
enviados de los clientes JMS.
<weblogic-enterprise-bean>
<ejb-name>InsuranceQuoteBean</ejb-name>
<message-driven-descriptor>
<pool>
<max-beans-in-free-pool>15</max-beans-in-freepool>
<initial-beans-in-free-pool>5</initial-beans-infree-
pool>
</pool>
</message-driven-descriptor>
...
</weblogic-enterprise-bean>
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.
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:
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.
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.
Pág. 33 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
Weblogic Server ofrece dos opciones ante esta situación con el fin de liberar memoría
en la caché:
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.
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.
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
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 idle-
timeout-seconds no haya expirado
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.
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 idle-
timeout-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.
<weblogic-enterprise-bean>
<ejb-name>ShoppingCartBean</ejb-name>
<stateful-session-descriptor>
<stateful-session-cache>
<max-beans-in-cache>1000</max-beans-in-cache>
<idle-timeout-seconds>60</idle-timeout-
seconds>
</stateful-session-cache>
</stateful-session-descriptor>
...
</weblogic-enterprise-bean>
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.
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
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.
<weblogic-enterprise-bean>
<ejb-name>OrderBean</ejb-name>
<entity-descriptor>
<pool>
<max-beans-in-free-pool>15</max-beans-in-freepool>
<initial-beans-in-free-pool>5</initial-beans-infree-
pool>
</pool>
<entity-cache>
<max-beans-in-cache>1000</max-beans-in-cache>
<idle-timeout-seconds>60</idle-timeout-seconds>
</entity-cache>
Para usarla, necesitamos definir una entidad de caché de nivel de aplicación que se
define en el fichero weblogic-application.xml:
<weblogic-application>
<ejb>
<entity-cache>
<entity-cache-name>appLevelCache1</entity-cache-
name>
<max-beans-in-cache>1000</max-beans-in-cache>
<caching-strategy>MultiVersion</caching-strategy>
</entity-cache>
...
Pág. 37 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
<weblogic-enterprise-bean>
<ejb-name>CorporateAddressRO</ejb-name>
<entity-descriptor>
<entity-cache-ref>
<entity-cache-name>appLevelCache1</entity-cache-
name>
<read-timeout-seconds>600</read-timeout-seconds>
<cache-between-transactions>true</cache-between-
transactions>
<concurrency-strategy>ReadOnly</concurrency-
strategy>
<estimated-bean-size>20</estimated-bean-size>
</entity-cache-ref>
...
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.
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.
Pág. 38 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
<weblogic-enterprise-bean>
<ejb-name>AccountEJB</ejb-name>
<entity-descriptor>
<entity-cache>
<max-beans-in-cache>1000</max-beans-in-cache>
<cache-between-transactions>True
</cache-between-transactions>
</entity-cache>
<persistence></persistence>
</entity-descriptor>
<jndi-name>AccountEJB</jndi-name>
</weblogic-enterprise-bean>
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.
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.‟
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.
Pág. 40 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
<weblogic-enterprise-bean>
<ejb-name>PurchaseOrderBean</ejb-name>
<entity-descriptor>
<entity-cache>
<concurrency-strategy>
Exclusive | Database | | Optimistic | ReadOnly
</concurrency-strategy>
</entity-cache>
</entity-descriptor>
</weblogic-enterprise-bean>
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.
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-cmp-
jar.xml poniendolo al valor true tal como se muestra a continuación:
<weblogic-rdbms-jar>
<enable-batch-operations>
True
</enable-batch-operations>
</weblogic-rdbms-jar>
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.
<weblogic-rdbms-jar>
<weblogic-query>
<query-method>
<method-name>findGoldCustomer</method-name>
<method-params>...</method-params>
</query-method>
<ejb-ql-query>...</ejb-ql-query>
<include-updates>True</include-updates>
</weblogic-query>
</weblogic-rdbms-jar>
• 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
<weblogic-cmp-jar>
…
<relationship-caching>
<caching-name>cacheMoreBeans</caching-name>
<caching-element>
<cmr-field>accounts</cmr-field>
<group-name>acct_group</group-name>
<caching-element>
<cmr-field>address</cmr-field>
<group-name>addr_group</group-name>
</caching-element>
</caching-element>
<caching-element>
<cmr-field>phone</cmr-field>
<group-name>phone_group</group-name>
</caching-element>
</relationship-caching>
…
</weblogic-cmp-jar>
Campos de grupos
<weblogic-rdbms-bean>
<ejb-name>MedicalBean</ejb-name>
<field-group>
<group-name>medical-data</group-name>
<cmp-field>insurance</cmp-field>
<cmr-field>doctors</cmr-fields>
</field-group>
</weblogic-rdbms-bean>
Pág. 43 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
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.
Tag <container-transaction>
Este tag contiene, a su vez, los tags <method> y <trans-attribute>. 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.
...</enterprise-beans>
<assembly-descriptor>
<container-transaction>
<method>
<ejb-name>JspSession</ejb-name>
<method-name>*</method-name>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
... </assembly-descriptor>
Pág. 44 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
<ejb-name>
o Especifica el nombre del EJB que aloja el método.
<method-intf>
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.
<method-name>
o Es el nombre de un método o *, que indica todos los métodos.
<method-params>
o Es opcional y contiene una lista de tags <method-param>. 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 *.
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.
Nivel de aislamiento
Pág. 45 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
<weblogic-ejb-jar>
…
<transaction-isolation>
<isolationlevel>
TRANSACTION_READ_UNCOMMITTED</isolation-level>
<method> <ejb-name>dogEJB</ejb-name>
<method-name>*</method-name> </method>
</transaction-isolation>
…
</weblogic-ejb-jar>
Consideraciones de diseño
Timeout de transacciones
Veamos ahora las características del mecanismo de timeout dentro del control
transaccional:
• 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
<weblogic-enterprise-bean>
<transaction-descriptor>
<trans-timeout-seconds>20</trans-timeout-
seconds>
</transaction-descriptor >
</weblogic-enterprise-bean>
Pág. 47 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
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.
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.
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.
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.
Pág. 49 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
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.
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.
Passive cookie
Pág. 50 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
• 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
Persistencia SSL
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
Pág. 51 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
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.
<session-descriptor>
<persistent-store-type>replicated</persistent-store-type>
<session-descriptor>
<session-descriptor>
<persistent-store-type>replicated_if_clustered</persistent-
store-type>
<session-descriptor>
<session-descriptor>
<persistent-store-type>file</persistent-store-type>
<persistent-store-dir>Directory Path</persistent-store-dir>
<session-descriptor>
Pág. 52 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
<session-descriptor>
<persistent-store-type>jdbc</persistent-store-type>
<persistent-store-pool>Data Source Name</persistent-store-
pool>
<session-descriptor>
Pág. 53 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
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.
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.
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.
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.
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
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.
fair-share-request-class>
<name>high_priority</name>
<fair-share>90</fair-share>
</fair-share-request-class>
<fair-share-request-class>
<name>low_priority</name>
<fair-share>10</fair-share>
</fair-share-request-class>
<response-time-request-class>
<name>fast_response_time</name>
<goal-ms>1000</goal-ms>
</response-time-request-class>
<response-time-request-class>
<name>slow_response_time</name>
<goal-ms>8000</goal-ms>
</response-time-request-class>
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.
<context-request-class>
Pág. 55 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
<name>simple_context</name>
<context-case>
<user-name>system</user-name>
<request-class-name>high_fairshare</request-class-name>
</context-case>
<context-case>
<group-name>everyone</group-name>
<request-class-name>low_fairshare</request-class-name>
</context-case>
</context-request-class>
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.
max-threads-constraint
min-threads-constraint
capacity
<max-threads-constraint>
<name>max_threads</name>
<count>10</count>
<connection-pool-name></connection-pool-name>
</max-threads-constraint>
Pág. 56 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
<min-threads-constraint>
<name>min_threads</name>
<count>1</count>
</min-threads-constraint>
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.
<capacity-constraint>
<name>my_capacity</name>
<count>50</count>
</capacity-constraint>
Es importante destacar, que las peticiones son rechazadas tanto si se alcanza el límite
de forma individual como de forma global.
<work-manager>
<name>priority_work_manager</name>
<fair-share-request-class>
<name>very_high_priority</name>
<fair-share>1000</fair-share>
</fair-share-request-class>
<min-threads-constraint>
<name>min_five_Threads</name>
<count>5</count>
<min-threads-constraint>
</work-manager>
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.
<self-tuning>
<fair-share-request-class>
Pág. 57 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
<name>HighFairShare</name> <target>mainserver</target>
<fair-share>500</fair-share>
</fair-share-request-class>
<max-threads-constraint>
<name>MoreThreads</name> <target>mainserver</target>
<count>20</count>
<connection-pool-name></connection-pool-name>
</max-threads-constraint>
<work-manager>
<name>priority_work_manager</name>
<target>mainserver</target>
<fair-share-request-class>HighFairShare</fair-share-
request-class>
<response-time-request-class xsi:nil="true"></response-
time-requestclass>
<context-request-class xsi:nil="true"></context-request-
class>
<max-threads-constraint>MoreThreads</max-threads-
constraint>
</work-manager>
</self-tuning>
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.
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 weblogic-
application.xml tal como se indica a continuación:
<weblogic-application>
<max-threads-constraint>
<name>app_max_threads</name>
<count>10</count>
</max-threads-constraint>
<min-threads-constraint>
<name>app_min_threads</name>
<count>5</count>
</min-threads-constraint>
<work-manager>
<name>AppScopedWorkManager</name>
</work-manager>
</weblogic-application>
<weblogic-web-app>
<wl-dispatch-policy>LowPriority</wl-dispatch-policy>
<work-manager>
<name>LowPriority</name>
Pág. 58 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
<fair-share-request-class>
<name>LowFairShare</name>
<fair-share>50</fair-share>
</fair-share-request-class>
<max-threads-constraint>
<name>LessThreads</name>
<count>2</count>
</max-threads-constraint>
</work-manager>
</weblogic-web-app>
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.
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.
<weblogic-web-app>
<wl-dispatch-policy>
stuckthread_workmanager
</wl-dispatch-policy>
<work-manager>
<name>stuckthread_workmanager</name>
<work-manager-shutdown-trigger>
<max-stuck-thread-time>60</max-stuck-thread-time>
<stuck-thread-count>5</stuck-thread-count>
</work-manager-shutdown-trigger>
</work-manager>
</weblogic-web-app>
Retrocompatibilidad
Pág. 59 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011
Para que ello sea posible, es necesario realizar uno de los dos cambios siguientes:
Pág. 60 / 60