InfV5 JASAS WLS BusinessLayer BestPractices V310

Oficina de Calidad
Subdireccin de Tecnologas de la Informacin
Best practices de desarrollo sobre

Oracle Weblogic Server
para la capa de negocio
Referencia documento:
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V310.doc
Fecha: 12 de enero de 2012
Versin: 3.1.0
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V310.doc, Ver. 3.1.0
12 de enero de 2012
Registro de Cambios
Fecha Autor Versin Notas
13 de Enero de 2011 Emilio Nestal 2.1.0 Versin inicial

14 de Abril de 2011 Emilio Nestal 2.2.0 Versin correspondiente a Abril de 2011
14 de Julio de 2011 Emilio Nestal 2.3.0 Versin correspondiente a Julio de 2011
13 de Octubre de Emilio Nestal 2.4.0 Versin correspondiente a Octubre de
2011 2011
12 de enero de 2012 Emilio Nestal 3.1.0 Versin correspondiente a Enero de 2012
Revisiones
Nombre Role
Jonathan Ortiz Advanced Support Engineer
Distribucin
Copia Nombre Empresa
1 Subdireccin de Tecnologas de la Servicio Andaluz de Salud, Junta de

Informacin Andaluca
2 Servicio de Coordinacin de Consejera de Innovacin, Junta de
Informtica de la Consejera de Andaluca
Innovacin
Pg. 2 / 84
12 de enero de 2012
ndice de Contenidos
CONTROL DE CAMBIOS ......................................................................................................................... 5

INTRODUCCIN ....................................................................................................................................6
OBJETIVOS DE ESTE DOCUMENTO .......................................................................................................... 7
BEST PRACTICES DE DESARROLLO SOBRE WEBLOGIC SERVER ............................................................... 8
BEST PRACTICES PARA JDBC ................................................................................................................ 9
Tecnologa 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
Gestin de transacciones ................................................................................................................ 15
Niveles transaccionales................................................................................................................... 15
BEST PRACTICES PARA JAVA PERSISTENCE API (JPA) ........................................................................ 17
Generacin de esquemas................................................................................................................. 18
Data Partitioning a travs de Eclipselink ....................................................................................... 23
Rendimiento de EclipseLink ............................................................................................................ 26
Integracin de EclipseLink con bases de datos Oracle................................................................... 33
BEST PRACTICES PARA JAVA MESSAGE SERVICE................................................................................. 34
Dos tipos de dominios JMS ............................................................................................................. 35
Arquitectura JMS ............................................................................................................................ 35
Operativa de clientes JMS .............................................................................................................. 36
Agregacin y flujo de mensajes ....................................................................................................... 36
Persistent Stores .............................................................................................................................. 36
Paging ............................................................................................................................................. 37
Tamao del buffer del mensaje ....................................................................................................... 37
Throttling ........................................................................................................................................ 38
Cuotas JMS ..................................................................................................................................... 39
Umbrales o threshold ...................................................................................................................... 40
Control de flujo ............................................................................................................................... 40
Gestin de expirados ....................................................................................................................... 41
Acuse de recibo (Acknowledgement)............................................................................................... 42
Store and Forward (SAF)................................................................................................................ 43
ANTIPATRONES PARA JAVA MESSAGE SERVICE ................................................................................... 45
Eleccin del tipo mensaje................................................................................................................ 45
Anti-Patrn: Fat Messages ............................................................................................................. 47
Anti-Patrn: Golden Hammers ....................................................................................................... 47
Anti-Patrn: Monolithic Consumer ................................................................................................ 48
BEST PRACTICES PARA ENTERPRISE JAVABEANS ................................................................................ 52
Interfaces EJB ................................................................................................................................. 52
Estructura de aplicaciones EJBs..................................................................................................... 53
Beans de tipo Stateless Session ....................................................................................................... 53
Message-Driven Beans (MDB) ....................................................................................................... 55
Stateful Session Beans ..................................................................................................................... 56
Pg. 3 / 84
12 de enero de 2012
Beans de entidad (Entity beans) ...................................................................................................... 60

Estrategias de concurrencia para Entity Beans .............................................................................. 63
Entity Bean Bulk Updates ............................................................................................................... 65
Cacheo de relaciones (relationship caching) .................................................................................. 66
Container-Managed Transactions (CMT)....................................................................................... 68
BEST PRATICES PARA CLUSTERING ...................................................................................................... 72
Balanceo de carg y failover ............................................................................................................ 72
Arquitectura bsica de un clster ................................................................................................... 73
Arquictura multi capa de un clster ................................................................................................ 73
Balanceadores de carga.................................................................................................................. 74
Replicacin de sesin ...................................................................................................................... 75
Replicacin basada en memora ..................................................................................................... 75
Persistenca basada en JDBC ......................................................................................................... 76
Persistenca basada en file system compartido ............................................................................... 76
Configuracin de los tipos de replicacin ...................................................................................... 76
BEST PRACTICES PARA WORK MANAGERS .......................................................................................... 78
Default Work Manager ................................................................................................................... 78
Clases de tipo Request .................................................................................................................... 78
Clases de tipo Fair Share Request .................................................................................................. 79
Clases de tipo Response Time Request ........................................................................................... 79
Clases de tipo Context Request ....................................................................................................... 79
Resctricciones (Constraints) ........................................................................................................... 80
Resctriccin Maximum Threads ...................................................................................................... 80
Resctriccin Minimum Threads ...................................................................................................... 80
Resctriccin Capacity ..................................................................................................................... 81
Clases y restricciones de tipo Referencing...................................................................................... 81
Global-Level Work Managers ......................................................................................................... 81
Work Manager a nivel de aplicacin .............................................................................................. 82
Work Managers a nivel de aplicaciones Web ................................................................................. 82
Work Manager para Stuck Threads ................................................................................................ 83
Colas de ejecucin (Execute queues) .............................................................................................. 83
Pg. 4 / 84
12 de enero de 2012
Control de cambios
Cambio Descripcin Pgina
1 No se realizan cambios en esta versin
Pg. 5 / 84
12 de enero de 2012
Introduccin
Este documento recoge una serie de recomendaciones de Oracle Soporte planteadas
como buenas prcticas de desarrollo para aplicaciones que hagan uso de Oracle
WebLogic Server 11gR1.
Estas recomendaciones estn encaminadas a minimizar los posibles problemas de

rendimiento en sistema de cualquier tamao y en la gran mayora de los casos se
basan en la experiencia de casos reales gestionados por Oracle Soporte.
Finalmente, este documento tambin recoge una serie de conceptos de componentes,

mdulos y tecnologas relacionadas con Oracle WebLogic Server 11gR1., que a juicio
de Oracle Soporte, deberan tenerse claros para asegurar la aplicacin de las
recomendaciones recogidas en este documento, y de manera general, entender los
productos Oracle sobre los que se sustentan los sistemas y aplicaciones.
Pg. 6 / 84
12 de enero de 2012
Objetivos de este documento

A lo largo de los puntos de este documento se ir definiendo una gua de buenas
prcticas para el desarrollo de aplicaciones sobre Oracle WebLogic Server 11gR1.
Esta gua contendr tanto prcticas recomendadas como prcticas a evitar y se

apoyar en ejemplos y en informacin que permita analizar las recomendaciones en
cada uno de los entornos de desarrollo y preproduccin.
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 gua de buenas prcticas tiene varios objetivos:
Aprovechamiento de las caractersticas del producto
o Rendimiento
o Escalabilidad
o Alta disponibilidad
o Balanceo de carga
Facilitar la implantacin y modificacin del aplicativo en produccin con

sistemas basados en Oracle WebLogic Server 11gR1.
Pg. 7 / 84
12 de enero de 2012
Best practices de desarrollo sobre Weblogic Server

<TODO>
Versin
Objetivo
Bussiness Layer
</TODO>
Pg. 8 / 84
12 de enero de 2012
Best Practices para JDBC

Tecnologa JDBC
JDBC es una API que proporciona una interfaz comn de programacin 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 caracterstica inherente de Java conseguida

por la mquina virtual. Las aplicaciones que utilizan JDBC no tienen que
preocuparse de la arquitectura de la mquina o del sistema operativo, ya que esto es
abstrado por la mquina virtual.
Java proporciona un amplio soporte para la gestin de objetos remotos a travs de su

Remote Method Invocation API y Enterprise Java Beans. Esto permite a los
desarrolladores, centrase ms en los procesos de gestin de datos y menos en
cuestiones particulares del sistema (transparencia de ubicacin).
JDBC se ha convertido en una API para el acceso a cualquier tipo de forma de

manejo de datos como hojas de clculo, ficheros planos y por supuesto, de bases de
datos.
JDBC est basado en el estndar de facto ODBC de Microsoft. ODBC por su parte,
est basado en la especificacin 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 implementacin para operaciones de bases de
datos. Podemos dividir los drivers en dos categoras:
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
Pg. 9 / 84
12 de enero de 2012
Los drivers JDBC drivers son una simple coleccin de clases que implementan
mtodos 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 acta como capa intermedia,

optimizando las conexiones para la base de datos, normalmente mediante un
pool de conexiones. Un pool de conexiones es una coleccin 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 especfica.
El grfico anterior, muestra cmo las aplicaciones pueden conectarse directamente a

una base de datos usando JDBC usando Weblogic Server, que a su vez utiliza
JDBC, para la conexin.
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 travs de una conexin ODBC client-configured. Una aplicacin 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
Pg. 10 / 84
12 de enero de 2012
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, implementacin multi-capa, utiliza un servidor de red para

pasar las peticiones JDBC a la base de datos.
Un driver de tipo 4 es una implementacin Java del driver nativo JDBC de la base de
datos. La base de datos y la aplicacin JDBC realizan llamadas Java-to-Java usando
este tipo de driver. Los drivers JDBC que permiten a una mquina 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 implementacin multi
capa.
Consideraciones sobre los drivers JDBC
La eleccin 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 ms rpido.

El driver Thin de Oracle 10g es significativamente ms rpido que el driver Thin
de 9i.
Pool de Conexiones
Una de las ventajas de usar un pool de conexiones sobre una conexin directa es que
las conexiones ya existirn cuando las aplicaciones quieran conectarse a una base de
datos.
Esto ahorra a las aplicaciones la sobrecarga de la creacin de conexiones. Incluso el

software de la capa intermedia, Weblogic Server, puede aplicar un balanceo de carga
mediante la asignacin de conexiones a aplicaciones usando una base de datos, y
luego liberando y ponindolas disponibles para otras aplicaciones cuando no estn
en uso.
El balanceo de carga puede incluso incluir un crecimiento y una reduccin dinmica

del nmero de conexiones en un pool de conexionespara adptarse a condiciones de
cambio de cargas. El pool de conexiones aade otras ventajas como la aplicacin de
seguridad a una conexin.
El grfico muestra que el servidor de aplicaciones aloja el pool de conexiones y que

las aplicaciones utilizan los pools en funcin de sus necesidades.
Pg. 11 / 84
12 de enero de 2012
Data Sources
Un data source es un concepto J2EE que permite abstraer una conexin 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 conexin 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 conexin.
El grfico muestra como las aplicaciones Java usan JNDI para obtener una referencia
a un data source. Esto lo hace con la llamada lookup(). La aplicacin Java toma
despus una conexin del data source usando una llamada al mtodo
getConnection(). A partir de ese momento, la aplicacin Java est lista para hacer
llamadas a la base de datos usando esa conexin.
Tamao del Pool de Conexiones
Capacidad Inicial: El nmero de conexiones fsicas a crear cuando se crea un

pool de conexiones. Es tambin el nmero mnimo de conexiones fsicas que el
pool de conexiones mantendr disponibles.
Capacidad Mxima: El nmero mximo de conexiones fsicas que el pool de

conexiones puede contener.
Incremento de Capacidad: El nmero de conexiones creadas al aadir nuevas

conexiones al pool de conexiones. Cuando no hay ms conexiones fsicas
disponibles para satisfacer las peticiones de conexin, WebLogic Server crea
este nmero de conexiones fsicas adicionales y las aade al pool de
conexiones.
Shrink Frequency
WebLogic Server reduce peridicamente el pool de conexiones a su capacidad inicial

en function del uso.
El parmetro Shrink Frequency se usa para especificar el nmero 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 produccin.
Pg. 12 / 84
12 de enero de 2012
Testeo de conexiones
Test Connection On Reserve: Habilita a WebLogic Server para hacer un test

sobre una conexin antes de drsela a un cliente. El test aade un pequeo
retraso en la peticin del cliente para una conexin del pool, pero asegura que
el cliente reciba una conexin viable.
Test Frequency: El nmero de segundos que pasa entre los tests que realiza
WebLogic Server sobre conexiones que no se estn usando. Las conexiones que
fallan en el test se cierran y se vuelven a abrir para intentar reestablecer una
conexin fsica vlida. Si se pone a 0, estos tests peridicos se deshabilitan.
Nota: Ambos parmetros 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
El row prefetching mejora el rendimiento al cargar multiples filas del servidor al

cliente en un nico acceso. El tamao ptimo del prefetch depende de las
particularidades de la consulta. En general, el incremento del tamao 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
envan 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 travs de
WebLogic Server, el row prefetching mejora el rendimiento mediante la
precarga de mltiples filas desde el servidor al cliente en un solo acceso.
WebLogic Server ignora esta opcin y no usa la precarga cuando el cliente y
WebLogic Server estn en la misma JVM.
Tamao del Row Prefetch: Si est habilitado el row prefetching, especifica el

nmero de filas que se precargan. El tamao ptimo del prefetch depende de las
particularidades de la consulta. En general, el incremento del tamao suele
mejorar el rendimiento, hasta que se alcance un valor particular. En este caso, no
tendramos una mejora muy significativa en el rendimiento. Muy raramente
conseguiremos mejorar el rendimiento al exceder de 100 filas.
Los valores mnimo y mximo para este parmetro 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 ms parmetros.
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 travs del parmetro Statement Cache Type. Es
Pg. 13 / 84
12 de enero de 2012
parmetro 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 tamao de la cach, Weblogic Server usa el parmetro Statement

Cache Size, que permite determinar el nmero de prepared y callable statements que
se almacenan en cach.
Dos caractersticas adicionales para esta caracterstica:
Cada conexin 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

opcin.En caso contrario, los valores mnimo y mximo para este parmetro son
respectivamente 0 y 1024.
PinnedToThread
PinnedToThread es una opcin que puede mejorar el rendimiento al permitir que las
execute threads mantengar la conexin a base de datos incluso despus de que la
aplicacin cierre la conexin lgica.
Cuando PinnedToThread est habilitado, WebLogic Server fija una conexin del
pool de conexiones a la hebra la primera vez que sta reserva la conexin. En el
momento que la aplicacin termina de usar la aplicacin e invoca a
connection.close(), devolviendo la conexin al pool, Weblogic Server mantiene esta
relacin y no la devuelve realmente. Cuando la aplicacin a travs de la hebra
vuelve a realizar una peticin a base de datos, ya tiene disponible una conexin a
sta.
Un efecto de esta configuracin, es que se reduce la potencial contencin que se crea

cuando mltiples hebras intentan reservar una conexin en un momento del tiempo
y existen suficientes conexiones dentro del pool para todas ellas.
En este caso, donde la aplicacin reserva ms de una conexin dentro de una misma
hebra de ejecucin, Weblogic Server crear una conexin adicional y la mantendr
asociada a dicha hebra gracias a esta funcionalidad.
Pg. 14 / 84
12 de enero de 2012
Batch Updates
Una aplicacin tpica puede llegar a ejecutar una gran cantidad de sentencias de
manipulacin 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.
Gestin de transacciones
La gestin de la transaccionalidad de una aplicacin 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 aplicacin.
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 transaccin.
Con el fin de reducir esta carga extra de trabajo, se puede recomendar que, en la
medida de lo posible, mltiples transacciones se unifiquen dentro del menor nmero
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 automticamente como
una transaccin separada.
Al deshabilitar el auto-commit e indicando explcitamente los lmites 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 tambin el mtodo Connection.getAutoCommit() que

devuelve el valor actual del modo auto-commit. Cuando se deshabilita el auto-
commit, sera necesario el uso de los mtodos Connection.start(),
Connection.commit() y Connection.rollback().
Niveles transaccionales
El nivel de aislamiento de una transaccin suele definirse como el balanceo de las

siguientes caractersticas:
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
Pg. 15 / 84
12 de enero de 2012
TRANSACTION_READ_COMMITTED
TRANSACTION_REPEATABLE_READ
TRANSACTION_SERIALIZABLE
Como veremos, cuando ms alta es la integridad de los datos, ms lento es el acceso.

Estos dos aspectos pueden ser controlados por el nivel de aislamiento de la
transaccin.
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
continuacin tenemos varios escenarios que muestran problemas de integridad:
Dirty reads: Una fila ha sido modificada por otro proceso y esa modificacin no
ha hecho commit an.
Non-repeatable read: Una fila ha sido modificada por otro proceso que ha
confirmado la modificacin..
Phantom row: Un fila ha sido eliminada por otro proceso, y el borrado no ha
sido confirmado an.
Volviendo a los cuatro niveles de aislamiento transaccionales:
TRANSACTION_READ_UNCOMMITTED: Se permiten Dirty reads, non-

repeatable read y phantom reads. Es el nivel ms permisivo.
TRANSACTION_READ_COMMITTED: No se permiten las dirty reads. Sin

embargo, si estn 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 estn permitidas.
TRANSACTION_SERIALIZABLE: No se permiten Dirty reads, non-repeatable

read ni phantom reads. Es el nivel ms restricctivo.
Pg. 16 / 84
12 de enero de 2012
Best Practices para Java Persistence API (JPA)

EclipseLink es un framework avanzado de persistencia y transformacin de objetos
que proporciona herramientas de desarrollo y capacidades en tiempo de ejecucin
que reducen el esfuerzo de desarrollo y mantenimiento e incrementan la
funcionalidad de las aplicaciones empresariales.
Con el uso de EclipseLink se puede integrar la persistencia y transformacin de

objetos en su aplicacin, mientras se permanece centrado en el problema principal
de obtener beneficios de una solucin eficiente, flexible y probada.
EclipseLink es adecuado para una amplia gama de arquitecturas Java 2 Enterprise

Edition (JEE) y aplicacin Java. La recomendacin es usar EclipseLink para disear,
implementar, desplegar y optimizar una capa de persistencia y transformacin de
datos avanzada que soporte gran variedad de fuentes de datos y formatos,
incluyendo los siguientes:
Relacional para persistencia transaccional de objetos Java para acceso a bases

de datos relacionales mediante drivers Java Database Connectivity (JDBC).
Tipo de datos objeto-relacional para persistencia transaccional de objetos Java

de propsito especial de representacin de datos estructurados optimizados
para almacenamiento en bases de datos de tipo objeto-relacional como Oracle
Database.
Sistema de informacin empresarial (EIS) para persistencia transaccional de

objetos Java para acceso a datos no relacionales usando el adaptador Java EE
Connector architecture (JCA) y algunos tipos de registros EIS soportados,
incluyendo indexados, mapeados, o XML.
XML para conversaciones no transaccionales y no persistentes (en memoria)

entre objetos Java y XML Schema Document (XSD) en base a documentos
XML usando Java Architecture for XML Binding (JAXB).
EclipseLink incluye soporte para EJB 3.0 y la API de Persistencia de Java (JPA) en
entornos Java EE y Java SE incluyendo integracin con gran variedad de servidores
de aplicaciones, entre los que se encuentran:
Oracle WebLogic Server

Oracle OC4J
Glassfish
Pg. 17 / 84
12 de enero de 2012
JBoss
varios contenedores web como Apache Tomcat.
EclipseLink permite capturar y definir fuente objeto a dato y representacin de

objeto a dato mapendolos en formato de metadatos eficiente y flexible,
aprovechando los metadatos mapeados con una nica session faade, lo que
proporciona soporte para acceso a datos, consultas, transacciones (ambos con y sin
controlador de transacciones externas), y caching.
Generacin de esquemas
Se tratarn los siguientes temas en este apartado:
@CascadeOnDelete
@Index
Adicin de cadenas a la sentencia CREATE TABLE
@CascadeOnDelete
ON DELETE CASCADE es una restriccin de tipo foreign key que automticamente
borra las filas dependientes. Use esta annotation para especificar que cuando se
realice una operacin de borrado sobre un objeto de la base de datos sea borrado
tambin en tablas secundarias o relacionadas.
Comportamiento de CascadeOnDelete
Realizar Hace esto...
CascadeOnDelete en
este objeto
Entidad Define que las tablas secundarias o unidas con join deben
borrarse en cascada
OneToOne mapping Borrado en cascada de objetos relacionales en la base de
datos. Slo permitido para mapeos de mappedBy/target
de foreign key OneToOne (debido a la restriccin de la
direccin)
OneToMany mapping Para OneToMany usando mappedBy o JoinComumn, el
borrado de un objeto relacional se hace en cascada en la
base de datos. Para OneToMany usando JoinTable, el
borrado de la table del join se hace en cascada en la base
de datos ( a los objetos target no se les puede aplicar
cascada incluso si son privados debido a la restriccin de
direccin).
ManyToMany El borrado de la tabla del join se hace en cascada en la
mapping base de datos ( a los objetos target no se les puede aplicar
cascada incluso si son privados debido a la restriccin de
direccin).
ElementCollection El borrado de la table collection se hace en cascada en la
mapping base de datos
Pg. 18 / 84
12 de enero de 2012
@CascadeOnDelete tiene el siguiente comportamiento:
Generacin DDL: Si se usa DDL generation, la restriccin generada incluir la

opcin de borrado en cascada.
Entidad: El borrado no ejecutar SQL para borrado de tablas secundarias o

unidas con join (la restriccin se encargar del borrado).
OneToOne: Si el mapping usa borrado en cascada u orphanRemoval. No se

ejecutar SQL para borrar el objeto destino.
OneToMany: Si el mapping usa borrado en cascada u orphanRemoval. No se

ejecutar SQL para borrar el objeto destino.
ManyToMany: No ejecutar SQL para borrar desde una tabla unida con join.
ElementCollection: No se ejecutar SQL para borrar desde una collection

table.
Cache: Los objetos con borrado en cascada sern eliminados de la cach y el

context o de persistencia.
Version locking: La version no se verificar en el borrado de un objeto en

cascada.
Eventos: El borrado de eventos no se ejecutar en objetos en cascada si los

objetos no se han cargado.
Cascading: La operacin de borrado debe configurarse en cascada en el

mapping si se est usando CascadeOnDelete.
Ejemplo @CascadeOnDelete
En este ejemplo se realiza el borrado en cascada de la tabla secundaria Employee, y
todas sus relaciones.
@Entity
@SecondaryTable(name="EMP_SALARY")
@CascadeOnDelete
public class Employee{
@Id
private long id;
Pg. 19 / 84
12 de enero de 2012
private String firstName;

private String lastName;
@Column(table="EMP_SALARY")
private String salary;
@OneToOne(mappedBy="owner", orphanRemoval=true,
cascade={CascadeType.ALL})
@CascadeOnDelete
private Address address;
@OneToMany(mappedBy="owner", orphanRemoval=true,
cascade={CascadeType.ALL})
@CascadeOnDelete
private List<Phone> phones;
@ManyToMany
@JoinTable(name="EMP_PROJ")
@CascadeOnDelete
private List<Project> projects;
...
}
Especificacin de Cascade on Delete en eclipselink-orm.xml : En el descriptor de

fichero eclipselink-orm.xml,hay que especificar cascade on delete como se muestra
en el siguiente ejemplo.
<cascade-on-delete>true</cascade-on-delete>
@Index
Un ndice es una estructura de base de datos definida para una tabla, para mejorar el
rendimiento de consultas y bsquedas de conjuntos de columnas. Use la annotation
@Index en el cdigo o el elemento <index> en el descriptor eclipselink-orm.xml para
crear un ndice en una tabla.
Un ndice puede definirse en una entidad o en un atributo. Para la entidad debe

definirse un conjunto de columnas.
La creacin de ndices es especfica de la base de datos. Algunas bases de datos no

soportan ndices. La mayora de las bases de datos auto indexan las columnas
primary key y foreign key. Algunas bases de datos soportan opciones avanzadas de
ndices DDL. Para crear ms ndices avanzados DDL, puede usarse un script DDL o
una consulta nativa.
@Index Attributes
Attribute Description Default Required?
catalog Catlogo del Default catalog No
INDEX.
columnNames Especifica el Para una Entity, la No requerido
conjunto de tabla. Para un cuando existen
columnas sobre atributo, la tabla y la annotations en un
las que el ndice columna. campo o mtodo.
est definido.
name El nombre del <table>_<column No
Pg. 20 / 84
12 de enero de 2012
INDEX. >_INDEX
(pero debe
proporcionarse un
nombre)
schema El esquema del Default schema No
INDEX.
table La tabla sobre la La tabla primaria de No
que est la entidad.
definido el
ndice, por
defecto para
entidades la
tabla primaria.
unique Especifica false No
cuando el ndice
es unique o no
es unique.
En este ejemplo se definen tres ndices, uno en first name, otro en last name y varias
columnas indexadas en first name y last name.
@Entity
@Index(name="EMP_NAME_INDEX", columns={"F_NAME","L_NAME"})
public class Employee{
@Id
private long id;
@Index
@Column(name="F_NAME")
private String firstName;
@Index
@Column(name="L_NAME")
private String lastName;
...
}
Tambin se puede crear un ndice en el descriptor eclipselink-orm.xml usando

<index>, como se muestra en el siguiente ejemplo. Pueden definirse columnas
usando el subelemento <column>. Todos los atributos soportados en la annotation
@Index estn tambin soportados en el elemento <index>.
<index name="EMP_NAME_INDEX" table="EMPLOYEE" unique="true">

<column>F_NAME</column>
<column>L_NAME</column>
</index>
Pg. 21 / 84
12 de enero de 2012
Adicin de cadenas a sentencias CREATE TABLE

Puede aadir una cadena al final de la sentencia CREATE TABLE cuando genera
DDL. Esto es til, por ejemplo, para crear tablas que sean transaccionales, puede
aadirse engine=Oracle al final de la sentencia de creacin para especificar que se
usar el motor de almacenamiento Oracle.
Aadir una cadena slo afecta a la generacin DDL. No afecta a otro

comportamiento en tiempo de ejecucin. Puede especificar cadenas usando
propiedades de unidad de persistencia o propiedades de sesin para aplicarlas a
todas las tablas en un contexto. Especifique cadenas en eclipselink-orm.xml para
aplicarlas a tablas individuales.
Propiedades de Unidad de Persistencia

Para unidad de persistencia, use la propiedad eclipselink.ddl-
generation.table-creation-suffix para aadir una cadena a todas las
tablas definidas en la unidad de persistencia. Para tablas individuales, use el atributo
creation-suffix en eclipelink-orm.xml para elementos de creacin de
tablas. Los siguientes elementos pueden tomar este atributo:
table
secondary-table
join-table
collection-table
table-generator
Pg. 22 / 84
12 de enero de 2012
Data Partitioning a travs de Eclipselink

Data Partitioning permite a una aplicacin escalar sus datos a travs de ms de una
mquina de base de datos. EclipseLink proporciona data partitioning a nivel de
Entidad para permitir que diferentes conjuntos de instancias de entidades para la
misma clase sean almacenados en una base de datos fsica diferente o nodos
diferentes de un cluster. Estn soportadas ambas, bases de datos comunes y bases de
datos en cluster. Los datos pueden particionarse tanto horizontalmente como
verticalmente.
Puede habilitarse partitioning en una entidad, relacin, consulta, o una unidad de

persistencia.
Polticas de partitioning
Para configurar data partitioning, use la annotation @Partitioned y una o ms
annotations de polticas de partitioning. Las annotations para definir las diferentes
polticas son:
@HashPartitioning Las particiones acceden al cluster mediante el hash

del valor del campo de un objeto, tales como ID o ubicacin. Todas las
escrituras o lecturas solicitadas para objetos con el mismo valor hash se envan
al mismo servidor. Si una consulta no incluye el campo hash como parmetro,
puede enviarse a todos los servidores y unir la respuesta de stos despus, o se
puede dejar al comportamiento por defecto de la sesin.
@PinnedPartitioning Solicitudes de pin para una nica conexin

pool/nodo. Esto permite partitioning vertical.
@RangePartitioning Las particiones acceden al cluster de base de datos

mediante un valor de campo del objeto, tales como ID, localizacin, o inquilino.
A cada servidor se le asigna un rango de valores. Todas las solicitudes de
escrituras y lecturas de objetos con valor en el rango se enviarn al mismo
servidor. Si una consulta no incluye el campo como parmetro, podr enviarse
a todos los servidores y unir la respuesta de stos despus, o se se puede dejar
al comportamiento por defecto de la sesin.
@ReplicationPartitioning Enva las solicitudes a un conjunto de

conexiones del pools/nodos. Esta poltica se usa para replicar datos entre de las
mquinas de un cluster de bases de datos. Slo las modificaciones de consultas
se replican.
Pg. 23 / 84
12 de enero de 2012
@RoundRobinPartitioning Enva solicitudes en round-robin al conjunto

de conexiones del pool/nodos. Esta poltica se usa para balanceamiento de
carga en consultas de lectura entre las mquinas del cluster de base de datos.
Necesita que la base de datos completa sea replicada en cada mquina, as que
no se soporta partitioning. Tanto los datos read-only como las escrituras sern
replicadas.
@UnionPartitioning - Enva consultas a todas las conexiones del pool y une

el resultado. Esto es para consultas o relaciones que necesitan datos de varias
particiones cuando se usa partitioning, como ocurre en una relacin de
particin cruzada ManyToMany.
@ValuePartitioning - Las particiones acceden al cluster de la base de datos

mediante un valor de campo del objeto, como ID, localizacin, o inquilino.
Cada valor se asigna a un servidor especfico. Todas las escrituras y lecturas
solicitadas se enviarn al mismo servidor. Si una consulta no incluye el campo
como parmetro, podr enviarse a todos los servidores y despus unir los
resultados, o se puede dejar al comportamiento por defecto de la sesin.
@Partitioning Los accesos a las particiones de un cluster de base de datos

se hacen mediante una poltica de partitioning customizada. Debe
proporcionarse la clase PartitioningPolicy e implementarse.
Las polticas de partitioning son objetos con nombre global en una unidad de
persistencia que son reusables entre diferentes descriptores o consultas. Esto mejora
la usabilidad de la configuracin, especficamente con annotations JPA y XML.
Si una transaccin modifica datos de varias particiones, debe usarse JTA para
garantizar el commit de los datos en 2 fases. Tambin puede configurarse una
conexin exclusiva en EntityManager para garantizar que un nico nodo se
encarga de una nica transaccin.
Ejemplos de Data Partitioning

Este ejemplo particiona los datos de Employee por el campo location. Los dos
primeros lugares, Gotham y Metropolis estn almacenados cada uno en una base de
datos separada. Las dems localizaciones estn almacenadas en la base de datos por
defecto. Project se particiona por rango utilizando el ID. Cada rango de valores de ID
se almacenan en una base de datos diferente. La relacin employees/project es un
ejemplo de una relacin de particin cruzada. Para permitir que los empleados y los
Pg. 24 / 84
12 de enero de 2012
proyectos se almacenen en bases de datos diferentes se usa una poltica de union y la

tabla join se replica a cada base de datos.
@Entity
@IdClass(EmployeePK.class)
@UnionPartitioning(
name="UnionPartitioningAllNodes",
replicateWrites=true)
@ValuePartitioning(
name="ValuePartitioningByLOCATION",
partitionColumn=@Column(name="LOCATION"),
unionUnpartitionableQueries=true,
defaultConnectionPool="default",
partitions={
@ValuePartition(connectionPool="node2", value="Gotham"),
@ValuePartition(connectionPool="node3", value="Metropolis")
})
@Partitioned("ValuePartitioningByLOCATION")
public class Employee {
@Id
@Column(name = "EMP_ID")
private Integer id;
@Id
private String location;
...
@ManyToMany(cascade = { PERSIST, MERGE })

@Partitioned("UnionPartitioningAllNodes")
private Collection<Project> projects;
...
}
@Entity
@RangePartitioning(
name="RangePartitioningByPROJ_ID",
partitionColumn=@Column(name="PROJ_ID"),
partitionValueType=Integer.class,
unionUnpartitionableQueries=true,
partitions={
@RangePartition(connectionPool="default", startValue="0",
endValue="1000"),
@RangePartition(connectionPool="node2", startValue="1000",
endValue="2000"),
@RangePartition(connectionPool="node3", startValue="2000")
})
@Partitioned("RangePartitioningByPROJ_ID")
public class Project {
@Id
@Column(name="PROJ_ID")
private Integer id;
...
}
Pg. 25 / 84
12 de enero de 2012
Rendimiento de EclipseLink
EclipseLink proporciona un conjunto diverso de caractersticas para medir y
optimizar el rendimiento de aplicaciones. Puede activar o desactivar la mayora de
las caractersticas en los descriptores o en la sesin, haciendo que cualquier resultado
mejore el rendimiento global.
Introduccin a Optimizacin
Las consideraciones de rendimiento estn presentes en todos los pasos del ciclo de
desarrollo. Aunque esto implique conciencia con problemas de rendimiento en el
diseo y la implementacin, tampoco significa que tenga lograr el mejor rendimiento
posible a la primera.
Por ejemplo, si la optimizacin complica el diseo, djelo para la fase final del
desarrollo. Pero debera planificar estas optimizaciones desde la primera iteracin,
para que sea ms fcil integrarlas despus.
El concepto ms importante asociado con tunear su aplicacin EclipseLink es la idea

de un enfoque iterativo. La forma ms efectiva de tunear su aplicacin es haciendo
lo siguiente:
Medir el rendimiento de EclipseLink con EclipseLink Profiler.
Identificar las Fuentes de problemas de rendimiento de aplicaciones y modificar

los componentes de aplicacin.
Medir el rendimiento de nuevo.
Para identificar los cambios que mejoran el rendimiento de su aplicacin, modifique

slo uno o dos componentes a la vez. Adems debera tunear su aplicacin en un
entorno que no est en produccin antes de desplegar la aplicacin.
Identificar las Fuentes de problemas de rendimiento

En esta seccin se describen los problemas de rendimiento ms comunes y se ofrecen
sugerencias para mejorar el rendimiento para algunas partes de una aplicacin
compatible con EclipseLink. Las partes de la aplicacin, donde pueden presentarse
problemas de rendimiento, son las siguientes:
Identificar la Optimizacin de Rendimiento General
Esquema
Pg. 26 / 84
12 de enero de 2012
Mapeos y descriptores
Sesiones
Cach
Acceso a datos
Consultas
Unidad de trabajo
Servidor de aplicaciones y Optimizacin de base de datos
Monitorizacin y Profiling de rendimiento

El reto ms importante para tunear el rendimiento es saber qu optimizar. Para
mejorar el rendimiento de su aplicacin, identifique las zonas de su aplicacin que
no trabajan con total eficiencia. EclipseLink performance profiler ayuda a identificar
problemas de rendimiento haciendo logs de estadsticas de rendimiento para todas
las consultas ejecutadas en una sesin determinada.
Nota: Debera considerar usar profilers generales de rendimiento como JDeveloper o

JProfiler para analizar problemas de rendimiento. Estas herramientas pueden
proporcionar ms detalles para diagnosticar correctamente un problema.
EclipseLink performance profiler hace logs de la siguiente informacin en el fichero

de log de EclipseLink
query class
domain class
tiempo total, tiempo de ejecucin total de la consulta, incluyendo consultas

anidadas(en milisegundos)
tiempo local, tiempo de ejecucin total de la consulta, excluyendo consultas

anidadas(en milisegundos)
nmero de objetos, nmero total de ojetos afectados
nmero de objetos manejados por segundos
logging, cantidad de tiempo invertido en imprimir mensajes de log (en

milisegundos)
Preparacin SQL, cantidad d tiempo invertido en preparar el script SQL (en

milisegundos)
Pg. 27 / 84
12 de enero de 2012
Ejecucin SQL, cantidad de tiempo invertido en ejecutar el script SQL (en

milisegundos)
obtener filas, cantidad de tiempo invertido en obtener las filas de la base de

datos ( en milisegundos)
cach, cantidad de tiempo invertido en buscar o actualizar el objeto en cach ( en

milisegundos)
construccin del objeto, cantidad de tiempo invertido en construir el objeto de

dominio (en milisegundos)
preparacin de la consulta, cantidad de tiempo invertido en preparar la consulta

previo a su ejecucin(en milisegundos)
Generacin SQL, cantidad de tiempo invertido en generar el script SQL antes de

enviarlo a la base de datos (en milisegundos)
Nota: Use EclipseLink profiler para hacer profiling de ejecuciones de casos de uso
bajo el modelo de ejecucin single-threaded finite para encontrar cuellos de botella.
No use EclipseLink profiler para habilitar monitorizacin de un servidor multihilo
con ejecuciones largas.
Cmo configurar EclipseLink Performance Profiler

Cuando usamos JPA el profiler puede establecerse en persistence.xml
poniendo la propiedad "eclipselink.profiler" a "PerformanceProfiler".
EclipseLink performance profiler es una instancia de la clase

org.eclipse.persistence.tools.profiler.PerformanceProfiler. sta
proporciona una API pblica que se detalla a continuacin:
logProfile habilita el profiler;
dontLogProfile deshabilita el profiler;
logProfileSummary organiza el log del profiler como un sumario de todas

las operaciones de profiling individuales incluyendo operaciones estadsticas
como la operacin de profiling que ha necesitado menos tiempo, el tiempo total
invertido en todas las operaciones, el nmero de objetos devueltos por consultas
de profiling, y el tiempo total invertido en cada clase de operacin de profiling;
logProfileSummaryByQuery organiza el log del profiler como un sumario

de las operaciones de profiling por consulta realizadas;
Pg. 28 / 84
12 de enero de 2012
logProfileSummaryByClass organiza el log del profiler como un sumario

de las operaciones de profiling por clase realizadas;
Salida de Performance Profiler

Begin Profile of{
ReadAllQuery(com.demos.employee.domain.Employee)
Profile(ReadAllQuery,# of obj=12, time=139923809,sql execute=21723809,
prepare=49523809, row fetch=39023809, time/obj=11623809,obj/sec=8)
} End Profile
La segunda lnea del perfil contiene la siguiente informacin de la consulta:
ReadAllQuery(com.demos.employee.domain.Employee): especifica la
consulta a la que se ha hecho profiling, y sus argumentos.
Profile(ReadAllQuery: comienzo del profile y tipo de consulta.
# of obj=12: nmero de objetos involucrados en la consulta.
time=139923809: tiempo total de ejecucin de la consulyta ( en

milisegundos).
sql execute=21723809: tiempo total invertido en ejecutar la sentencia SQL.
prepare=49523809: tiempo total invertido en preparer la sentencia SQL.
row fetch=39023809: tiempo total invertido en obtener columnas de la base

de datos.
time/obj=116123809: number of nanoseconds spent on each object.
obj/sec=8: nmero de objetos manejados por segundo.
Monitorizacin de Rendimiento
Use el monitor de rendimiento para proporcionar informacin detallada de profiling
y monitoring en un entorno de servidor multihilo.
Habilite el monitor en persistence.xml como se muestra a continuacin:
<property name="eclipselink.profiler" value="PerformanceMonitor"/>
El monitor de rendimiento tambin puede activarse a travs de cdigo utilizando

una SessionCustomizer.
Pg. 29 / 84
12 de enero de 2012
El monitor de rendimiento hace un volcado de las estadsticas acumuladas cada

minuto en el log de EclipseLink.
Las estadsticas contienen tres conjuntos de informacin:
Info: Estadsticas de datos con informacin constante, como nombre de

session, o tiempo de login.
Counter: Estadsticas que son contadores acumulativos de operaciones totales,

tales como aciertos de cach, o ejecuciones de consulta.
Timer: Estadsticas acumulativas de medidas de tiempo total (en

nanosegundos) para un tipo de operacin especfico, lecturas, escrituras,
operaciones de base de datos.
Las estadsticas se agrupan generalmente por total y tambin por tipo de consulta,
clase de consulta y nombre de consulta. Los contadores y temporizadores,
generalmente, se registran para las mismas operaciones, as que el tiempo por
operacin tambin podra calcularse.
El tiempo entre volcados de estadsticas puede configurarse con la API

PerformanceMonitor mediante la API setDumpTime(long). Si el volcado de los
resultados no es el deseado, dumpTime puede establecerse a un valor mayor como
Long.MAX_VALUE. Tambin se puede acceder a la estadstica a travs de
programacin mediante la API getOperationTime(String).
El monitor de rendimiento tambin puede configurarse con un peso de profile.
Los pesos de profile estn definidos en SessionProfiler e incluyen:
NONE No se registran estadsticas.
NORMAL Se registran estadsticas informativas.
HEAVY Se registran estadsticas informativas, de contadores y

temporizadores.
ALL Se registran todas las estadsticas (esta es la opcin por defecto).
Ejemplo de salida del profiler
Performance Monitor:1279113281664
Operation Value (ns)
Counter:CacheHits 1,375,664
Pg. 30 / 84
12 de enero de 2012
Counter:CacheMisses 327
Counter:ClientSessionCreates 1,204,817
Counter:ConnectCalls 2
Counter:DataModifyQuery 48
Counter:DataModifyQuery:inventory 21
Counter:DataModifyQuery:order 27
Counter:DeleteObjectQuery 67,792
Counter:DeleteObjectQuery:Customer 1
...
Counter:ReadAllQuery 1,041,767.
Counter:ReadAllQuery:Item.findByCategory 733,827
Counter:ReadAllQuery:Item.findByCategory:CacheHits 733,779
Counter:ReadAllQuery:Item.findByCategory:CacheMisses 50
...
Counter:ReadObjectQuery 1,058,273
Counter:ReadObjectQuery:Item:item 130,063
Counter:ReadObjectQuery:Item:item:CacheHits 130,063
Counter:ReadObjectQuery:Item:item:CacheMisses 1
Counter:UnitOfWorkCommits 72,568
Counter:UnitOfWorkCreates 471,491
Counter:UnitOfWorkRollbacks 1
Counter:UpdateObjectQuery 71,498
Counter:UpdateObjectQuery:Customer 62,531
...
Info:LoginTime Wed Jul 14 08:55:41 EDT 2010
Info:SessionName file:/scratch/user_domains/servers/mt-1/app.jar
Timer:Caching 6,411,372,000
Timer:ConnectionManagement 17,225,641,000
Timer:DeleteObjectQuery 41,351,430,000
Timer:DeleteObjectQuery:Customer 4,441,000
Timer:DeleteObjectQuery:Customer:QueryPreparation 86,000
Timer:DeleteObjectQuery:Customer:SqlGeneration 28,000
Timer:DeleteObjectQuery:Customer:SqlPrepare 72,000
Timer:DeleteObjectQuery:Customer:StatementExecute 2,265,000
...
Timer:InsertObjectQuery 69,111,086,000
Timer:Logging 4,236,000
Timer:Merge 1,144,400,000
Timer:ObjectBuilding 31,914,397,000
Timer:QueryPreparation 984,396,000
Timer:ReadAllQuery 260,943,930,000
Timer:ReadAllQuery:Item:Item.findByCategory 14,790,333,000
Timer:ReadAllQuery:Item:Item.findByCategory:ObjectBuilding 250,959,000
Timer:ReadAllQuery:Item:Item.findByCategory:QueryPreparation 1,880,000
Timer:ReadAllQuery:Item:Item.findByCategory:RowFetch 113,552,000
Timer:ReadAllQuery:Item:Item.findByCategory:SqlGeneration 522,000
Timer:ReadAllQuery:Item:Item.findByCategory:SqlPrepare 2,055,000
Timer:ReadAllQuery:Item:Item.findByCategory:StatementExecute
107,382,000
...
Pg. 31 / 84
12 de enero de 2012
Timer:Register 3,272,443,000
Timer:RowFetch 25,340,990,000
Timer:Sequencing 1,352,326,000
Timer:SqlGeneration 6,646,000
Timer:SqlPrepare 19,536,031,000
Timer:StatementExecute 508,589,220,000
Timer:TXAfterCompletion 1,854,152,000
Timer:TXBeforeCompletion 169,381,843,000
Timer:UnitOfWorkCommit 167,483,825,000
Timer:UpdateObjectQuery 46,440,589,000
Timer:UpdateObjectQuery:Customer 40,466,433,000
Timer:UpdateObjectQuery:Customer:QueryPreparation 867,496,000
Timer:UpdateObjectQuery:Customer:SqlGeneration 98,000
Timer:UpdateObjectQuery:Customer:SqlPrepare 1,319,333,000
Timer:UpdateObjectQuery:Customer:StatementExecute 32,901,366,000
Monitorizacin de consultas
Use Query Monitor para medir las ejecuciones de consultas y los aciertos de cache.
Esto puede ser til para anlisis de rendimiento en sistemas complejos. Habilite
Query Monitor de alguna de estas 2 formas:
Establezca la propiedad del sistema

org.eclipse.persistence.querymonitor=true.
En persistence.xml, establezca <property name="eclipselink.profiler"
value="QueryMonitor"/>
El monitor vuelca el nmero de aciertos de la cach y el nmero de ejecuciones que

producen las consultas una vez cada 100 segundos.
Pg. 32 / 84
12 de enero de 2012
Integracin de EclipseLink con bases de datos Oracle
Aunque Eclipselink es totalmente independiente de cualquier motor de bases de

datos, puede integrarse y aprovechar todas las funcionalidades no estndares de
stos.
En el caso de base de datos Oracle, EclipseLink ofrece soporte a las siguientes

funcionalidades de Oracle RDBMS:
LOB's
NChar's
XMLType's
TIMESTAMP (TZ, LTZ)'s
Native batch writing
Structured object-relational data-types
PLSQL data-types y stored procedures/functions
VPD y proxy authentication
RAC
XDK XML parser
Hierarchical selects (Select by prior)
Returning clause
Flashback history y flashback queries
Stored procedures, output parameters y output cursors
Oracle AQ
Soporte de EclipseLink para procedimientos almancenados y triggers

Como se ha comentado anteriormente, Eclipselink soporta procedimiento y
funciones almacenadas as como disparadores o triggers.
Este soporte se realize a travs de la anotacin @NamedStoredProcedureQuery y de

las clases StoredProcedureCall, StoredFunctionCall y PLSQLStoredProcedureCall, y
cubre las siguientes funcionalidades:
Parmetros de tipo IN
Parmetros de tipo OUT
Parmetros de tipo INOUT
Result sets
Parmetros de tipo CURSOR OUT
Object-relational datatypes (Struct, Array)
Oracle PLSQL types como TABLE, RECORD, BOOLEAN
Uso de stored procedure en named query y dynamic query
Uso de stored procedure para sobrecargar la persistencia de entidades,
actualizaciones, eliminacin y consultas.
Uso de stored procedure para sobrecargar el mapeo de consultas, inserciones y
eliminaciones.
En el caso del uso de triggers que actualizan datos que se requieren en la aplicacin
tenemos dispones las anotaciones @ReturnInsert, @ReturnUpdate y ReturningPolicy
para dicha funcionalidad.
Pg. 33 / 84
12 de enero de 2012
Best Practices para Java Message Service
Un sistema orientado a mensajera es aquel que a travs de un sistema de

mensajera, permite el intercambio de informacin entre procesos basndose en
mensajes.
Java Message Service (JMS) el API estandar para el acceso a sistema de mensajera 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 estndar de Java para acceder a productos de tipo
Enterprise Messaging (EM).
Por tanto, a travs 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

estndar para la creacin, envo y recepcin de mensajes
El grfico muestra cmo 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 especificacin JMS define muchos aspectos de los mensajes, como su formato y su

interaccin con los distintos proveedores de servicios. Sin embargo, la especificacin
JMS no se ocupa de temas como:
Balanceo de Carga
Tolerancia a fallos
Notificacin de errores
Administracin
Seguridad e integridad de los mensajes
Protoco de envoi para mensajes binarios
El grfico 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.
Pg. 34 / 84
12 de enero de 2012
Dos tipos de dominios JMS
La especificacin 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 especificacin JMS clasifica en terminos generales todos los productos de

mensajera en uno de estos dominios.
Un ejemplo de dominio point-to-point es una aplicacin que enva 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 aplicacin que publica el valor
de una accin en mtiples sistemas de venta de acciones que previamente
estaban suscritos.
El grfico muestra como en la mensajera 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 mensajera empresarial. JMS permite a
las aplicaciones Java compartir un sistema de mensajera para el intercambio de
mensajes. Simplifica el desarrollo de aplicaciones proporcionando una interfaz
estndar para la creacin, envo y la recepcin 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.
Pg. 35 / 84
12 de enero de 2012
El grfico muestra que para que un proveedor pueda enviar un mensaje,

necesitamente previamente crear un connection factory y una conexin con el
servidor JMS.
Un objeto ConnectionFactory encapsula informacin de configuracin de conexiones

y habilita a las aplicaciones JMS para la creacin de conexiones. Cuando se establece
la conexin, se invoca a una sesin 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 conexin JMS.
Usar la conexin para crear una sesin.
Acceder a los destinos, ya sean de tipo queue o de tipo topic a travs de JDNI.
Usar la sesin y el destino para establecer si se va a producir o consumir
mensajes.
Crear y enviar mensajes o recibir y consumir mensajes.
Agregacin y flujo de mensajes

Existen ocasiones donde desde un mismo punto y con el mismo destino se envian
varios mensajes asncronos. En esta situacin 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 travs de listeners de mensajes.
Se permite mltiples mensajes en una misma llamada de red.
Puede parametrizarse la cantidad maxima de mensajes a travs de la connection
factory.
Persistent Stores
Si el nmero de mensajes almacenados incrementa, el almacenamiento necesario

para persistir los mensajes se incrementay por tanto, aumenta la cantidad de
memoria necesaria para la ejecucin 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 travs de
JDBC.
Veamos a continuacin comparacin entre ambas opciones:
Ambos tienen la misma semntica de transacciones y garantas

Ambos tienen la misma interfaz de aplicacin.
Los almacenes de archivos suelen ser generalmente ms rpidos y fciles de
configurar.
Los almacenes de archivos son ms flexibles para el volcado o paging de
mensajes no que no es necesario persistir.
Pg. 36 / 84
12 de enero de 2012
Los almacenes JDBC pueden hacer ms fcil 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 mquina de la red.
Persistencia basada en ficheros
En el caso de la persistencia basada en ficheros es necesario definir la poltica de

escritura sncrona que se va a emplear. Esta poltica afecta en el rendimiento de los
almecenes JMS, en la escalabilidad y en la fiabilidad general del sistema.
Las opciones de poltica vlidas son:
Direct-Write, donde las escrituras en el almacen se hacen directamente a disco.

Esta poltica est soportada en Oracle Solaris, HP-UX, y MS Windows. En este
ltimo caso, MS Windows, esta opcin generalmente es ms rpida que la
opcin 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 poltica es la ms rpida, pero la menos fiable desde el punto de visdta
transaccional. Puede ser ms de 100 veces ms rpido que otras polticas, pero
los cortes de luz fallos del sistema operativo pueden causar prdidas
mensajes duplicados.
Cache-Flush, donde las transacciones no se pueden completar hasta que todas

las escrituras se enven a disco. Esta poltica es fiable y escala bien cuando el
nmero de usuarios simultneos incrementa.
Paging
Durante situaciones de gran carga de mensajes, stos se paginan en disco para

conservar memoria.
En esta situacin, hay que tener en cuenta que:
Para mejorar el rendimiento, se recomienda que el directorio de paginacin debe

ser diferente del persistent store o almacen del servidor JMS.
Una paginacin excesiva podra degradar el rendimiento.
Se puede minimizar la paginacin mediante:

Incremento el tamao del buffer del mensaje
Incremento del tamao de heap de la JVM
Usando tcnicas de throttling
La paginacin est siempre habilitada en WebLogic Server. Si no se especifica un

directorio de paginacin, 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.
Tamao del buffer del mensaje
Pg. 37 / 84
12 de enero de 2012
La opcin 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 mximo de 512 megabytes.
Cuanto ms grande es este parmetro, ms 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 opcin Paging Directory con la intencin de reducir el uso de
memoria.
Es importante destacar que este parmetro no es una quota. Si el nmero de

mensajes en el servidor supera el umbral, el servidor escribir mensajes a disco y los
desaloja de memoria tan rpido 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 ms rpido 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 trfico de mensajes bajo condiciones de un alto volumen puede ser impredecible y

producirse a diferentes ritmos de llegada y salida:
En esta situacin:
Los mensajes se pueden producir mucho ms rpido de los que tardan en

consumirse, causando una congestin.
Esta condicin requiere que el mensaje que se enva pase por el control de flujo.
El throttling tambin aborda el problema de que los productores saturen a los

consumidores, compartan o no los mismos recursos.
En la mayora de los sistemas de mensajes, el emisor del mensaje es ms rpido 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.
Tcnicas para la implementacin de throttling
La implmentacin de Weblogic Server de JMS proporciona las siguientes tcnicas de

throttling:
Configuracin de cuotas de mensajes, la configuracin de cuotas ayuda a evitar

que el servidor se quede sin memoria.
Pg. 38 / 84
12 de enero de 2012
Tuning flow control:

El control de flujo es configurable a travs 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 tambin puede
expecificarse en nmero de bytes. Es esta situacin, se fuerza a los producers a
ir ms lento mediante el retraso inducido en las llamadas que producen el
mensaje de respuesta.
El diseo de aplicaciones usando un patrn de tipo peticin/respuesta:

El patrn de peticin/respuesta es un mtodo efectivo y comn de throttling
que se incorpora al diseo de una aplicacin. En esta tcnica, el que hace la
peticin 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 envo 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.
Configuracin de poltica de expiracin de mensajes:

Se dice que un mensaje expira, si este es consumido, borrado, o es redirigido a
otro destinatario. Se puede usar esta caracterstica para aliviar las condiciones
de desbordamiento, ya que provoca la limpieza y eliminacin de los mensajes
ms antiguos.
Cuotas JMS
Mximo nmero de bytes.
Define el nmero 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 lmite.
Es importante recordar que un volumen excesivo de bytes puede causar una

saturacin de memoria, Oracle recomienda que el mximo corresponda con la
cantidad de memoria del sistema disponible despus de contabilizar las aplicaciones
desplegadas y su consumo de memoria.
Nmero mximo de mensajes
Define el nmero mximo de mensajes que pueden ser almacenados en un servidor

JMS. Un valor de -1 elimina cualquier lmite por parte de WebLogic Server.
Es importante recordar que un volumen excesivo de bytes puede causar una

saturacin de memoria, Oracle recomienda que el mximo corresponda con la
cantidad de memoria del sistema disponible despus de contabilizar las aplicaciones
desplegadas y su consumo de memoria.
Pg. 39 / 84
12 de enero de 2012
Poltica de bloqueo de envos (Blocking Send Policy)
Determina si el servidor JMS de Weblogic Server puede entregar los mensajes ms

pequeos antes que los ms grande cuando un destinatario ha excedido si nmero
mximo de mensajes.
Por tanto, a travs de esta tcnica, desactivamos la poltica FIFO que impide que el
servidor JMS entregue mensajes pequeos cuando haya mensajes grandes ya
esperando por espacio, al permitir que los mensajes pequeos se adelanten a los
grandes cuando hay espacio suficiente para mensajes pequeos en el destinatario.
Esta poltica se define slo en el servidor JMS, no se puede establecer en los

destinatarios individuales.
Tamao mximo de mensaje
Define el nmero mximo de bytes permitido en mensajes individuales en un

servidor JMS de Weblogic Server.
El tamao 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 nmero 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

nmero 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 nmero de mensajes, a travs de messages

threshold high y messages threshold low.
Control de flujo
Flow Maximum
El nmero mximo de mensajes por segundo permitido para un productor que est
experimentando una condicin de umbral (threshold condition). Cuando se controla
el flujo de un productor, nunca podr sobrepasar el nmero FlowMaximum de
mensajes por segundo.
Si un productor no est limitando su flujo cuando se alcanza una condicin umbral,

el lmite de flujo inicial se fija en FlowMaximum. Si un productor ya est limitando
su flujo cuando se alcanza una condicin umbral (el lmite de flujo es inferior a
FlowMaximum), el productor continuar con su lmite hasta la prxima vez que se
evale el flujo.
Flow Minimum
Pg. 40 / 84
12 de enero de 2012
El nmero mnimo de mensajes por segundo permitido por un productor que est
experimentando una condicin umbral. Es el lmite 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 perodo de tiempo, en segundos, mientras que un productor ajusta su flujo desde
el nmero FlowMaximum de mensajes hasta el FlowMinimun, viceversa.
Flow Steps
El nmero 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 nmero 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, reducirn su
velocidad si un servidor JMS o un destino alcanzan su umbral mximo.
Gestin de expirados
La poltica de expiracin define qu accin debe tomar un destinatario en caso de

que se encuentre un mensaje expirado. La poltica puede descartar el mensaje,
descartar el mensaje y registrar su eliminacin, o redireccionar el mensaje a un
destinatario alternativo.
No se recomienda el uso del parmetro Expiration Logging Policy ya que se

considera en estado deprecated en esta versin de WebLogic Server 10g y
superiores.
En su lugar, Oracle recomienda el uso de Message Life Cycle Logging, que

proporciona una vista ms comprensiva de los eventos bsicos por los que pasarn
los mensajes JMS una vez que son aceptados por un servidor JMS, incluyendo datos
detallados de la expiracin del mensaje.
Configuracin de polticas de expiracin
Las plantillas JMS proporcionan una forma eficiente de definir mltiples

destinatarios, sean topics o queues, con caractersticas y ajustes similares.
Si se usan plantillas JMS para configurar mltiples destinatarios, se puede usar el

campo Expiration Policy para configurar una poltica de expiracin en todos los
destinatarios. Para anular o modificar la poltica de expiracin para destinatarios
especficos, se puede modificar a nivel de cada destinatario de forma particular.
Para configurar una poltica de expiracin de mensaje en una plantilla existente para
los destinatarios, se puede seleccionar uno de las siguientes opciones de la lista de
Polticas de Expiracin en la pgina Delivery Failure de la pestaa de Configuracin:
Discard: Elimina los mensajes expirados del sistema de mensajes. La eliminacin

de mensajes no se registra, y los mensajes no se redirigen a otra ubicacin.
Pg. 41 / 84
12 de enero de 2012
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
caracterstica ha sido declarada como deprecated.
Redirect: Mueve los mensajes expirados de su ubicacin actual al destino

definido como Error Destination para el destinatario.
Escaneo de mensajes expirados
La poltica de expiracin definir la cantidad de tiempo en que los mensajes

expirarn y lo que ocurre una vez que expiran. Sin embarego, los mensajes no se
eliminan necesariamente del sistema ni se movern 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 pestaa General en sobre la pestaa de Configuracin. 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 exploracin. Para
deshabilitar la exploracin, introducir un valor de 0 segundos.
Los mensajes expirados se eliminarn de forma pasiva del sistema cuando se

descubran.
Acuse de recibo (Acknowledgement)
Se recomienda usar las pliticas de acuse de recibo DUPS_OK_ACKNOWLEDGE y

AUTO_ACKNOWLEDGE ya que poseen un mejor rendimiento que la plitica
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 creacin del objeto de sesin desde la conexin, tal como se
muestra a continuacin:
Session session = connection.createSession(false,

Session.AUTO_ACKNOWLEDGE);
Pg. 42 / 84
12 de enero de 2012
Store and Forward (SAF)
Store and forward (SAF) es un mecanismo asncrono de comunicacin 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 situacin, 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 aplicacin A se
ejecuta en un Weblogic Server local y se comunica con la aplicacin 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 situacin, la aplicacin A enva un
mensaje a la aplicacin 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 aplicacin B cuando est disponible.
SAF usar un sistema unificado de subsistemas de almacenamiento de Weblogic

Server 10g y posteriors. A travs 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 rpida y fiable de mensajes en las aplicaciones que corren
en WebLogic Server
Asegura la entrega secuencial de mensajes mediante el mecanismo Unit-of-

Order
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 nmero de mensaje en la fuente destino es mayor o igual que el tamao

configurado como Window Size.
Pg. 43 / 84
12 de enero de 2012
Ha esperado el tiempo indicado a travs del parmetro Window Interval, lo que

suceda antes.
El intervalo de ventana, Window Interval, tiene efecto y mejora el rendimiento slo

en casos donde el que reenva est capacitado para reenviar mensajes tan rpido
como lleguen. En este caso, en lugar de reenviar inmediatamente los nuevos
mensajes que llegan, el que reenva, se pausa en un intento de acumular ms
mensajes y reenviarlos como un proceso por lotes.
Tamao de Ventana
Para WS-RM, se define como el nmero mximo de mensajes no confirmados, o

unacknowledged messages, permitido entre una fuente y un destino durante una
conversacin.
En caso de definirse, un agente emisor debe esperar para reenviar un mesaje de tipo
batch hasta que el nmero de mensajes en la fuente destino sea mayor igual que
este valor.
Pg. 44 / 84
12 de enero de 2012
Antipatrones para Java Message Service
JMS es una especificacin que define una interfaz para un servicio de mensajera
compatible con Java. Es una especificacin de interfaz, no una implementacin, ya
que los detalles de implementacin se dejan a los proveedores. JMS proporciona una
forma de producir y consumir mensajes.
Como tal, la API de mensajera es engaosamente simple. La mayor parte del

tiempo, se crean, envan y se reciben mensajes. Las aplicaciones resultantes estn
dbilmente acopladas, son flexibles, razonablemente eficientes, y pueden ser
altamente fiables. Adems, puesto que la especificacin JMS puede compartir el
contexto de transaccin JTA, se puede alcanzar complejidad suficiente para manejar
de forma robusta aplicaciones transactionally-sound.
Adicionalmente, los MDBs, o message-driven beans, permiten consumir al mismo

tiempo mensajes JMS en el contexto de una aplicacin EJB. Los MDBs son
transaccionales, sin estado, y orientados a los consumidores de mensajes asncronos.
En este mbito, donde JMS es un API simple de mensajera, y los MDBs son un
modelo de componentes que lo soporta en el contexto de un contenedor EJB,
trataremos el tema de anti-patrones en cada una de las tres principales reas de
aplicaciones JMS:
Qu hay dentro del mensaje? El contenido del mensaje depender de la

aplicacin, pero es fcil desviarse de los principios de diseo prctico y
eficiente. El mensaje es la interface. Si un mensaje es demasiado grande o
demasiado complejo, la interface tendr problemas.
Cmo se consumen los mensajes? Los consumidores suelen ser la pieza ms

elegante de una solucin de mensajera. Los consumidores pueden tener
muchas responsabilidades, que van desde la filtracin y la difusin al control
de mensajes. Se necesita cierta habilidad y delicadeza para disear un buen
consumidor.
Cmo crear el mensaje? Contrariamente a la intuicin, la creacin del mensaje

es probablemente el menos importante de los tres componentes principales de
una aplicacin JMS. Una vez definido el contenido, crear y enviar el mensaje
es relativamente sencillo, pero debe ser consciente de unos pocos anti-
patrones como el manejo de cadenas de texto.
Veremos en detalle, haciendo una mirada crtica hacia lo que es probable que falle,
cada uno de los elementos, como el payload, el tipo de mensaje y el mensaje mismo.
Eleccin del tipo mensaje
La unidad bsica en cualquier sistema dbilmente acoplado basado en mensajera es

el contenido del mensaje. Puede dividirse el contenido en tipo de carga y estructura.
Del mismo modo que la programacin Java eficaz demanda buenas interfaces, las
aplicaciones de mensajera dependern del contenido y la estructura del mensaje.
Cuando se genera un mensaje, JMS permite varias opciones en la estructura del
mensaje:
Pg. 45 / 84
12 de enero de 2012
Message: Suele tratarse de un mensaje de reconocimiento, no require payload.
TextMessage, simple: Para JMS, el texto es texto, pero vamos a dividir los
mensajes de texto en diferentes versiones sencillas y versiones decoradas. Un
simple mensaje de texto utiliza texto sin formato, con delimitadores simples
de estructura. El texto simple es fcil de crear, fcil de consumir, y
razonablemente eficiente para muchas aplicaciones. Las desventajas son que
no proporciona meta-datos, con lo que se consigue menos acoplamiento, bajo
rendimiento para acceso aleatorio, pero un parseo no sencillo.
TextMesssage, decorado: Pueden aadirse etiquetas al texto para dar pistas

sobre la estructura. Con esto, se puede estructurar la semntica completa del
mensaje. Simple Object Access Protocol (SOAP) hace exactamente eso:
proporciona una estructura conveniente, genrica y estndar para los
mensajes. Tambin puede utilizarse XML para estructurar slo el payload del
mensaje. Una ventaja de esta opcin es que puede proporcionarse meta-
informacin en el mensaje. Una desventaja es que hay que pagar una
penalidad de procesamiento significativa para producir y consumir mensajes.
Hablaremos ms sobre este tema cuando se discuta el impacto de XML en los
productores y los consumidores.
Objetos. Si el productor y el consumidor se construyen usando el mismo

lenguaje, entonces se podra serializar un objeto en el payload del mensaje. La
ventaja de esta opcin es que es una forma eficaz de crear y consumir el
mensaje. La desventaja es que este mtodo depende de la complejidad del
objeto serializado y que limita a los consumidores que pueden reconstruir el
objeto.
MappedMessage: es quizs el tipo de mensaje ms verstil. El mensaje "mapa"

contiene claves predefinidas que apuntan a ubicaciones en el payload del
mensaje. De esta manera, puede enviar un mensaje de ndole flexible y
dinmica, que soporta parmetros opcionales. La ventaja de esta opcin es
que los mappedmessages permiten bajo acoplamiento, acceso aleatorio muy
eficiente, y flexibilidad razonable en tipos de mensajes. La desventaja es que
hay que enviar los mappedmessages con el mensaje, lo que puede limitar el
rendimiento.
BytesMessage y StreamMessage: Cuando se usan bytes sin formato, los

productores y los consumidores que utilizan este tipo de mensajes debe
entender la estructura completa del payload. StreamMessage guarda el orden
y el tipo de los parmetros del payload, pero BytesMessage no lo hace. La
ventaja de esta opcin es que estos mensajes pueden ser muy eficientes. La
desventaja es que el productor y el consumidor necesitan estar muy
acoplados. La opcin de BytesMessages rara vez se utiliza, a menos se est
enviando un mensaje estandarizado que comprendan ambas partes como un
tipo MIME.
Por supuesto, ninguna estructura del mundo le ayudar si no se presta atencin al

contenido. Con mucha frecuencia, los mensajes contienen datos extraos que no
necesitan ser incluidos en el mensaje para llevar a cabo su funcin. Echemos un
vistazo a un antipatrn relacionado con el contenido del mensaje.
Pg. 46 / 84
12 de enero de 2012
Anti-Patrn: Fat Messages
Cuando los desarrolladores crean una estructura de mensaje, pocos ponen atencin
en la optimizacin del mensaje, pero deberan. Slo debera transmitirse el mensaje
mnimo que permite a un consumidor realizar el trabajo requerido. Qu datos
adicionales pueden colarse en nuestros mensajes?
Datos derivados: No incluya datos que el consumidor pueda obtener

fcilmente. Por ejemplo, puede deducirse fcilmente una edad a partir de la
fecha de nacimiento.
Datos que satisfacen necesidades futuras: No especule. Si no los necesita, no

los incluya. Un mensaje debe satisfacer el conjunto actual de requesitos de
negocio no los requisitos actuales y adems posibles requisitos futuros.
Duplicacin: No duplique para una mayor comodidad. Muchas estructuras

XML y estructuras de objetos puede duplicar los datos. Por ejemplo, si las
direcciones de facturacin y envo son las mismas, entonces puede ponerse
por defecto la direccin de envo a la direccin de facturacin, y procesar esa
informacin en el cliente.
Herencia y serializacin: Al serializar un objeto, tenga en cuenta que va a

serializar el conjunto de predecesores. Si esta lista es demasiado larga, el el
valor total del tamao ser muy alto. En ese caso, se debera utilizar otro tipo
de payload del mensaje.
Es muy importante que, su mensaje es su interface, por lo que es fundamental,

disearlo cuidadosamente y teniendo en cuenta el mtodo principal de interfaz.
Anti-Patrn: Golden Hammers
Cuando se tiene un martillo (golden hammer), todo parece un clavo. Para el

software de mensajera, XML es el ltimo golden hammer. La eleccin del tipo de
payload del mensaje tendr un impacto crtico sobre la complejidad del
procesamiento de mensajes. Tenga en cuenta que cuando cambia a XML el tipo de
mensaje que enva va a depender de su aplicacin. XML tiene claras ventajas que
atraen a los aficionados a la mensajera: un buen meta-modelo, estructura
convincente, riqueza y la flexibilidad. El problema es que el costo de XML y la
complejidad es a menudo prohibitivo para problemas simples.
Por esta razn, debe limitarse el uso de XML para un conjunto limitado de
circunstancias:
El bajo acoplamiento supera los problemas de rendimiento.

La aplicacin necesita meta-datos pesados.
Los productores y los consumidores son aplicaciones dispares, posiblemente
con diferentes programas de mantenimiento o desarrollo.
Solucin: La regla general es que debe usarse XML cuando los requisitos de
rendimiento son ms indulgentes y los meta-datos son ms importantes, como
escribir en un archivo o comunicarse con una aplicacin externa. Internamente, la
aplicacin debe utilizar un mecanismo ms especializado como un MappedMessage
Pg. 47 / 84
12 de enero de 2012
o ObjectMessage. Por ejemplo, una aplicacin de un punto de venta se comunica

internamente con mensajes mapped, pero peridicamente actualiza el inventario con
una aplicacin externa mediante mensajes XML.
Tenga en cuenta que nuestro modelo de mensajera puede cambiar en funcin de los
requisitos de la aplicacin. La caja registradora y el servidor de la contabilidad se
encuentran dentro de la misma aplicacin, en el mismo lenguaje, y con el mismo
programa de mantenimiento. Podemos y debemos jugar con un mayor rendimiento
y simplicidad para conseguir un acoplamiento bajo. Sin embargo, la aplicacin de
inventario tiene circunstancias diferentes. Es una aplicacin diferente con un
conjunto diferente de necesidades, y es probable que funcione con un programa de
mantenimiento diferente. XML es apropiado en este caso.
Anti-Patrn: Monolithic Consumer
A menudo, los equipos de desarrollo divididen una aplicacin de mensajera

trazando una clara lnea entre el productor y el consumidor, y con ello suele creerse
que han llegado a un diseo completo.
Normalemente, esto no suele ser suficiente. Veamos el consumidor siguiente, un

componente EJB para una entrada de pedidos, en forma de menssage-driven bean.
1. public class OrderRequestReceiverMDB

2.
3. implements javax.ejb.MessageDrivenBean,
4.
5. javax.jms.MessageListener {
6.
7.
8. private MessageDrivenContext ctx;
9.
10.
11. public void setMessageDrivenContext(MessageDrivenContext
ctx) {
12.
13. this.ctx = ctx;
14.
15. }
16.
17.
18. public void ejbCreate() {}
19.
20.
21. public void onMessage(Message message)
22. {
23.
24.
25. if (message instanceof MapMessage) {
26.
27.
28. MapMessage mapMessage = (MapMessage)message;
29.
30.
31. try {
32.
33.
34. String orderId = mapMessage.getString("Order ID");
35.
36. String productId = mapMessage.getString("Product ID");
37.
Pg. 48 / 84
12 de enero de 2012
38. int quantity = mapMessage.getInt("Quantity");

39.
40. double price = mapMessage.getDouble("Price");
41.
42.
43. OrderRequest orderRequest =
44.
45. <strong> new OrderRequest(orderId, productId, quantity,
price);
46.
47.
48. recordOrder(orderRequest);
49.
50.
51. OrderStatus status = fulfillOrder(orderRequest);
52.
53.
54. notifyOrderStatusSubscribers(status);
55.
56.
57. } catch (JMSException jmse) {
58.
59. jmse.printStackTrace();
60.
61. }
62.
63.
64. }
65. else
66. {
67.
68. System.err.println("OrderRequest must be a MapMessage
type!");
69.
70. }
71.
72. }
73.
74.
75. public void ejbRemove() {}
76.
77. }
78.
79.
El fragmento no es demasiado largo, pero es ms complejo de lo que debera ser.

Tambin falla en la separacin de los cometidos del modelo de negocio y del
consumidor. As como no queremos procesar la lgica de negocio en nuestras vistas,
tampoco queremos que la lgica de negocio se haga notar en nuestros consumidores.
Eche un vistazo a grandes rasgos. Estos tres mtodos pertenecen claramente al
modelo de negocio. Ellos asumen reglas de negocio, o la ausencia de ellas, en base a
la secuencia y a las condiciones con las que el MDB los llama.
Solucin: Delegacin, en nuestro caso, podemos fcilmente refactorizar mtodos de

negocio complejos con un controlador de mensajes. No necesitamos construir un EJB
completo. Un plain old java object (POJO) se adapta a nuestros propsitos tan bien
como un controlador. A continuacin, utilizamos MDB como una capa fina que
simplemente recibe la solicitud, crea un objeto, y hace marshalling de los datos
directamente a nuestro controlador. Aqu est el cdigo refactorizado para el
mtodo onMessage:
1. public void onMessage(Message message) {

2.
Pg. 49 / 84
12 de enero de 2012
3.
4. if (message instanceof MapMessage) {
5.
6.
7. MapMessage mapMessage = (MapMessage)message;
8.
9.
10. try {
11.
12.
13. String orderId = mapMessage.getString("Order ID");
14.
15. String productId = mapMessage.getString("Product ID");
16.
17. int quantity = mapMessage.getInt("Quantity");
18.
19. double price = mapMessage.getDouble("Price");
20.
21.
22. OrderRequest orderRequest =
23.
24. new OrderRequest(orderId, productId, quantity, price);
25.
26.
27. OrderRequestHandler handler = new OrderRequestHandler();
28.
29. handler.handle(orderRequest);
30.
31.
32. } catch (JMSException jmse) {
33.
34. jmse.printStackTrace();
35.
36. }
37.
38.
39. }
40. else {
41.
42. System.err.println("OrderRequest must be a MapMessage
type!");
43.
44. }
45.
46. }
47.
48.
En general, es recomendable mantener las siguientes caractersticas en sus mtodos

de mensajera en sus productores y los consumidores:
Deben ser cortos: sern mucho ms difcil mantener que los mtodos largos.
Separacin de cometidos, deje que su controlador de mensajes se ocupe del

mensaje y deje que su modelo de negocio se ocupe del negocio. Esta filosofa,
har que sea ms fcil cambiar los componentes del middleware, para mantener
y extender su modelo de negocio, y para la construccin de pruebas
automatizadas.
Mejor escriba la unidad de pruebas primero, es mucho ms difcil disear una

prueba, por ejemplo de JUnit, para un componente mal diseado.
Pg. 50 / 84
12 de enero de 2012
Cuando se descarta el antipatrn de golden hummer y se piensa en el diseo de

productores y consumidores, lo normal es sorprenderse de las posibilidades de
diseo mucho ms simples y de mejor rendimiento que existe. Mediante elecciones
eficaces en la delegacin y el modelo de mensajera, pueden simplificarse
drsticamente los productores y consumidores.
Pg. 51 / 84
12 de enero de 2012
Best Practices para Enterprise JavaBeans
La especificacin Enterprise JavaBeans (EJB) es una especificacin de arquitectura

de componentes que define la estructura de beans, la estructura de contenedores en
los cuales operan, y los mtodos para la interaccin con sus clientes.
Infraestructura de servicios, implementacin de servidor de aplicaciones y la

implementacin del cliente se definen por los desarrolladores y por el fabricante del
servidor de aplicaciones. Para ms informacin sobre EJBs y para ver la
especificacin visitar
http://java.sun.com/products/ejb/index.html.
Cada EJB tiene un enfoque de diseo en particular y unos requerimientos para su

construccin. 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 gestin 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
Pg. 52 / 84
12 de enero de 2012
Estructura de aplicaciones EJBs

Una aplicacin EJB est compuesta por
Es una archivo JAR

Uno o ms EJBs.
Estructura mnima de una aplicacin EJB estndar 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 especficas 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 caractersticas:
Proporcionan servicios no conversacionales

No mantiene ningn estado del cliente con el que dialogan.
Son sncronos
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.
Gestin 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
mltiples 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 nmero de instancias que mantiene para hacer el servidor ms
escalable.
La especificacin EJB indica que una sesin EJB slo puede ser accedida por un
cliente en cualquier momento. Esto significa que si un contenedor slo cre una
instancia EJB y hay 10 clientes solicitando el uso de dicha instancia, slo un cliente
Pg. 53 / 84
12 de enero de 2012
podr acceder al mismo tiempo. El resto de los clientes debern 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 perodo de timeout, RMI request timeout, despus del cual, la
llmada al mtodo falla y el bean queda libre de nuevo.
El grfico anterior muestra cinco clientes intentando acceder a un EJB en un

contenedor. Dado que el pool para este tipo se ha dijado para un mximo de tres
beans, dos de los clientes se bloquearn en espera del acceso.
El grfico anterior muestra el flujo de creacin de un stateless EJB en el pool, como lo

avandona para atender una aplicacin, 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-beans-
in-free-pool en el fichero weblogic-ejb-jar.xml. Por defecto, este valor es 0.
Cuando la llamada al mtodo se completa, la instancia EJB se devuelve al pool libre.

Dado que WebLogic Server desvincula al bean del cliente despus de cada llamada,
la instancia que un cliente usa puede cambiar de invocacin en invocacin.
Si todas las instancias de una clase EJB estn activas y se alcanza el max-beans-in-
free-pool, las nuevas peticiones de clientes sobre las clases EJB se quedarn
bloqueadas hasta que un EJB activo complete la llamada al mtodo. Si la transaccin
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.
Tamao 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 aplicacin
debido a la creacin de los instancias necesarias.
Si el nmero de EJBs de tipo stateless session es muy alto, el pool contiene instancias
inactivas que consume memoria. Si el nmero es muy bajo, un cliente puede no
obtener una instancia cuando lo necesite.
Pg. 54 / 84
12 de enero de 2012
Normalmente max-beans-in-free-pool debe ser igual al nmero de hebras en la

instancia del servidor, de forma, que cuando una hebra intente completar una
peticin, siempre exista una instancia disponible.
Configuracin 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 nmero 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
activacin del bean desde el free pool, en lugar de inicializarlo y luego activarlo. Por
defecto, initial-beans-in-free-pool est a 0.
El tamao mximo 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>
Message-Driven Beans (MDB)
Los Message-driven beans se introdujeron como parte de la especificacin EJB 2.0.

Estos beans se comportan de manera similar a los beans de tipo stateless session,
pero son asncronos.
Los componentes sncronos son aquellos que implementan un bloqueo y esperan su

comportamiento. Por ejemplo, cuando un cliente invoca a un mtodo en un bean
stateless session, la aplicacin cliente se bloquea y espera a que el bean complete la
ejecucin. La aplicacin cliente no puede continuar hasta que el bean haya acabado.
En cambio, en un modelo asncrono, un cliente puede invocar un bean y no tener

que esperar a que el mtodo se complete antes de continuar con otras actividades.
Los Message-driven beans son componentes asncronos que desacoplan lo beans de
sus usuarios.
Los MDB dependen en gran medida de los conceptos de mensajera que se definen
como parte de la especificacin JMS. La especificacin JMS define un conjunto de
interfaces que abstraen los detalles de implementacin de sistemas middleware
orientados a mensajes. Los clientes JMS envan mensajes a destinatarios JMS
Pg. 55 / 84
12 de enero de 2012
alojados en servidores de aplicaciones. La publicacin 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 grfico muestra un cliente entregando mensajes en un destinatario JMS y a su vez

los mensajes son consumidods por diferentes MDBs.
Configuracin del pool para MDBs
Se puede gestionar el pool de MDB bien limitando el nmero de instancias o bien

definiendo un tamao inicial del pool, tal como se muestra a continuacin.
<ejb-name>InsuranceQuoteBean</ejb-name>
<message-driven-descriptor>
<pool>
pool>
</pool>
</message-driven-descriptor>
...
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
travs de mltiples 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 peticin al mismo bean stateful que almacena su
informacin de estado.
Gestin 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 ningn umbral que aplique a un grupo de tipos de EJBs juntos.
Adems, slo se puede controlar el nmero de EJBs que se permiten en cacheno
Pg. 56 / 84
12 de enero de 2012
hay mecanismos para controlar la cache, por ejemplo, por la cantidad de memoria
ocupada por la suma de las instancias.
Con este nivel de gestin de cach, hay que contestar a estas preguntas:
Cmo de grande se quiere la cach?

Qu ocurre con los EJB cuando la cach se llena?
El grfico muestra que el servidor de aplicaciones alojar los stateful session beans
hasta el nmero especificado en la opcin 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 estn disponibles inmediatamente para las peticiones de los
clientes.
El grfico siguiente se muestra el cache de WebLogic Server y los procesos en los

cules 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 sesin con el bean. Mientras la sesin est
activa, la instancia se cachea en memoria y cuando la sesin se acaba, la instancia se
destruye.
El proceso de activacin 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
Pg. 57 / 84
12 de enero de 2012
se llena y cuando el objeto de sesin 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 situacin con el fin de liberar memora
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 reduccin del nmero de EJBs que estn
consumiendo parte de la cach de forma que un slot quede disponible para otro EJB.
Configuracin del tamao de la cache
Determinar el tamao apropiado de cach para el conjunto de beans de tipo stateful

session requiere un trabajo de anlisis y un amplio conocimiento del aplicativo.
El tamao 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 estn activos
simultneamente 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 tamao aproximado de cada tipo EJB, el nmero 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
administracin.
Finalmente, hay que considerar la opcin del clustering como solucin de cache
remota, ya que la replicacin 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
operacin sea eficiente en el servidor.
Si un EJB excede su valor <idle-timeout-seconds> especificado en el archivo META-

INF\weblogic-ejb-jar.xml file, puede ser destrudo por Weblogic Server.
Pero debemos tener en cuenta que un EJB es elegible para passivation si no ha

excedido su valor de <idle-timeout-seconds>, no est participando en una
transaccin, y no se encuentra ejecutando un mtodo.
Por tanto, slo ciertos tipos de EJBs son elegibles para el proceso de passivation.
Pg. 58 / 84
12 de enero de 2012
Polticas para la gestin de la cache
Cuando se activa la poltica LRU para la gestin de la cache, el contenedor realiza las
siguientes operaciones:
Enva instancias a disco, tan pronto como una instancia se vuelve inactiva por
idle-timeout-seconds, independientemente del valor de max-beans-in-cache.
Tambin realiza esta operacin si se alcanza max-beans-in-cache, aunque idle-
timeout-seconds no haya expirado
Elimina una instancia en modo passivated de disco despus de que se vuelva

inactiva por idle-timeout-seconds despus de la passivation. Esto se le denomina
eliminacin 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 idle-

timeout-seconds no haya expirado.
Configuracin 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 estn usando,

Weblogic Server provoca que se pase a pasivo algunos de esos beans aunque no
hayan alcanzado su lmite 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 slo cuando el EJB es elegible para ello y hay
presin 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 explcita para EJBs que hayan
alcanzado idle-timeout-seconds modificando el elemento cache-type del archivo
weblogic-ejb-jar.xml.
Especificar LRU como poltica, si se requiere una proceso de passivation ms

agresiva de EJBs.
Especificar NRU cuando haya presin de memoria en cach y se quieran
mantener en memoria los beans que el cliente utilice ms frecuentemente.
Cuando escasean los recursos y la cach necesita memoria, Weblogic Server examina
los EJBs que estn acercndose a su lmite de max-beans-in-cache. De esos beans,
Pg. 59 / 84
12 de enero de 2012
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.
Alternativamente, se puede ajustar el valor de los descriptores maxbeans- in-cache y

el idle-timeout-seconds de un EJB de tipo stateful sesin, tal como se muestra a
continuacin:
* @ejbgen:session max-beans-in-cache="1000" idle-

timeoutseconds="60"
* ejb-name = "ShoppingCartBean"
<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>
...
Beans de entidad (Entity beans)
Cuando decimos que un EJB es persistente, nos referimos a que los datos del EJB
persistirn o existirn 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 agregacin
de objetos que gestiona el EJB.
Cada vez que los atributos de los objetos en memoria se modifican, sus homlogos
persistentes se actualizan automticamente. Ya que el valor del EJB se almacena de
manera persistente, mltiples 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 travs de un single
object, permitiendo slo a un single client el uso del objeto al mismo tiempo, o puede
crear dos copias del dato persistente donde el contenedor sera 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 mltiples para gestionar cmo mltiples clientes
Pg. 60 / 84
12 de enero de 2012
comparten los mismos datos. Este es un concepto un poco complicado que

Weblogic Server aplica de mltiples formas.
Configuracin 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 <entity-cache> para albergar un tag <max-beans-in-cache>, ya

que tiene el mismo significado que en los stateful session bean, controla el nmero
de beans en el pool que se permiten en memoria al mismo tiempo. El tag <pool> es
igual que en los stateless session beans, tal como se muestr a continuacin:
<ejb-name>OrderBean</ejb-name>
<entity-descriptor>
<pool>
pool>
</pool>
<entity-cache>
<idle-timeout-seconds>60</idle-timeout-seconds>
</entity-cache>
Caches combinadas para EJBs Entity
El cacheo a nivel de aplicaciones tiene las siguientes ventajas:
Reduce el nmero 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

fragmentacin. 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 cachs 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 aplicacin que se
define en el fichero weblogic-application.xml:
<weblogic-application>
<ejb>
<entity-cache>
<entity-cache-name>appLevelCache1</entity-cache-
name>
<caching-strategy>MultiVersion</caching-strategy>
</entity-cache>
...
Pg. 61 / 84
12 de enero de 2012
Adems de una referencia a una entidad de cach de nivel de aplicacin definida en

el fichero weblogic-ejb-jar.xml:
<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>
...
Cada valor del elemento <entity-cache-name> en weblogic-ejb-jar.xml debe coincidir

con el valor de un elemento <entity-cache-name> en weblogic-application.xml.
Cache y transacciones
Si hacemos un llamada del contenedor para invocar al mtodo ejbLoad() por cada
transaccin simple, podemos encontrarnos con un problema de lentitud en el
procesamiento de stas.
Aunque esta tcnica se realiza para prevenir problemas de sincronizacin, En

algunos casos, es posible cambiar este comportamiento para optimizar el
procesamiento.
Para hacerlo, hay que poner el tag <cache-between-transactions> en el archivo

weblogic-ejb-jar.xml.
Es importante destacar que si ms de un cliente est accediendo a los datos al mismo

tiempo, puede haber prdida de datos con se usa esta tcnica y adems no estar
disponible en entornos basados en clsteres.
Veamos el grfico anterior:
Pg. 62 / 84
12 de enero de 2012
1. Un cliente llama a un mtodo que genera una transaccin.

2. Comienza una transaccin.
3. Si cache-between-transactions es false, la llamada del contenedor ejbLoad() antes
de ejecutar el mtodo, de lo contrario el mtodo se ejecuta.
4. Cuando la transaccin se confirma, commit, se produce la llamada a ejbStore().
<ejb-name>AccountEJB</ejb-name>
<entity-descriptor>
<entity-cache>
<cache-between-transactions>True
</cache-between-transactions>
</entity-cache>
<persistence></persistence>
</entity-descriptor>
<jndi-name>AccountEJB</jndi-name>
Estrategias de concurrencia para Entity Beans
Dado que mltiples 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 ms 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 sern tpicamente datos. Se puede dar una
situacin en que ms de un cliente est accediendo a la misma primary key a travs
del entity bean, y por tanto al mismo dato. Es lo que se llama un dirty read.
Finalmente, recordar que la eleccin de la estrategia adecuada para una aplicacin

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 transaccin.
Bloqueaa otras peticiones para la instancia EJB hasta que la transaccin 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.
Pg. 63 / 84
12 de enero de 2012
ReadOnly
Activa un nueva instancia para cada transaccin, 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 ms antiguaos
Invalida los read-only beans cuando se llama al mtodo invalidate() y envia un
mensaje multicast a travs 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 transaccin.
El contenedor EJB verifica que no ha cambiado ningn dato actualizado por la

transaccin antes de la confirmacin de la misma, commit, y el contenedor EJB
deshace la transaccin si se produjo algn 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 permita 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
mtodo EJB en una transaccin, WebLogic Server bloquea la instancia EJB durante la
transaccin. Otros clientes que soliciten el mismo EJB o mtodo se bloquearn hasta
que se complete la transaccin 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
transaccin para obtener los ltimos datos de EJB. La peticin para confirmar los
daots se pasa posteriormente a la base de datos. Y por tanto, sta maneja toda la
gestin de bloqueos y la deteccin de deadlock para los datos de EJBs.
Pg. 64 / 84
12 de enero de 2012
Se puede especificar cacheo de read-only entity bean a nivel de aplicacin o de

componente. Para habilitar el cacheo de read-only en entity bean es necesario:
Especificar la opcin ReadOnly en la opcin del descriptor de despliegue

concurrency-strategy para cada archivo JAR EAR.
Especificar el elemento concurrency-strategy para cachs de nivel de
aplicaciones (EARS) en el archivo weblogic-application.xml.
Especificar el elemento concurrency-strategy para cachs de nivel de
componente (JARS) en el archivo weblogic-ejb-jar.xml.
Invalidar un read-only entity bean mediante la llamada al mtodo 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 mtodo invalidate(), los read-only entity beans se invalidan en el
servidor local, y se enva 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 ningn bloqueo

en el contenedor EJB ni la base de datos mientras la transaccin est en proceso.
Cuando se especifica esta opcin, el contenedor EJB se asegura que los datos que se
actualizan con la transaccin no han cambiado. Realiza un smart update
comprobando los campos antes del commit de la transaccin.
<ejb-name>PurchaseOrderBean</ejb-name>
<entity-descriptor>
<entity-cache>
<concurrency-strategy>
Exclusive | Database | | Optimistic | ReadOnly
</concurrency-strategy>
</entity-cache>
</entity-descriptor>
Entity Bean Bulk Updates
Existen situaciones donde mltiples instancias del mismo bean de entidad de tipo
CMP cambian en una misma transaccin. 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 actualizacin de mltiples entradas en una tabla de la base de
datos en un batch de sentencias SQL/DML. Con ello se mejora el rendimiento
haciendo mltiples inserts, deletes o updates para los beans CMP en un envo a la
base de datos.
Pg. 65 / 84
12 de enero de 2012
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 continuacin:
<weblogic-rdbms-jar>
<enable-batch-operations>
True
</enable-batch-operations>
</weblogic-rdbms-jar>
Directiva include-updates
De acuerdo con la especificacin EJB, las actualizaciones hechas por una transaccin
deben ser reflejadas en los resultados de los query-finders y ejbSelects emitidos
durante la transaccin.
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 decisin de deshabilitar cache flushing depende de si el rendimiento es ms

importante que ver la mayor cantidad de datos. Poniendo include-updates a False
obtenemos el mejor rendimiento pero las actualizaciones de la transaccin actual no
se reflejan en la query.
<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>
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 mltiples consultas utilizando una join query para los mismos.
Veamos algunas caractersticas:
En entity relationships, se usan mltiples 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-cmp-

jar.xml.
Relationship caching usa joins multinivel para cargar mltiples beans usando
una sentencia SQL.
Pg. 66 / 84
12 de enero de 2012
Configuracin del cacheo de relaciones
Veamos un ejemplo de configuracin del cacheo de relaciones:
<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>
No hay limitacin en el nmero de caching-elements a especificar. Sin embargo, si se

disponen muchos niveles, se podra obtener un impacto negativo en el rendimiento
de la transaccin.
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 relacin,
de forma que cuando se carga un bean como resultado de ejecutar una query o fruto
de una relacin, slo se cargan los campos mencionados en el grupo.
<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>
El mecanismo de eager loading es una forma de especificar qu datos se cargan y si

se cachean en la duracin de una transaccin. Si un mtodo de tipo finder se usa en
una transaccin, y en una transaction posterior el bean devuelto por el mtodo
finder vuelve a ser accedido, usando por ejemplo un mtodo get, el campo accedido
se carga de nuevo, ya que los datos podran haber cambiado.
Pg. 67 / 84
12 de enero de 2012
Si est habilitado el cacheo entre transacciones, entonces se usar el mecanismo

eager loading la primera vez para cachear los datos, pero posteriormente se usarn
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 cargarn 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 mtodos deben tener una transaccin activa
durante su ejecucin y el contenedor comenzar la transaccin antes de llamar al
mtodo y hacer commit o rollback de la transaccin una vez completado el mtodo.
El grfico muestra el proceso:

El cliente hace la invocacin.
El contenedor empieza la transaccin como parte del proceso de pre-invocacin.
Se invoca el bean.
Se hace rollback o commit de la transaccin como parte del proceso de post-
invocacin.
Tag <container-transaction>
Cuando se indica el tag <transaction-type> como container, el tag <container-

transaction> se usa para indicar el tipo de comportamiento de la transaccin que
debe existir para los diferentes mtodos del bean.
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 mtodos.
El segundo especifica uno o ms mtodos 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>
Una revisin rpida de la sintaxis del tag <method>:
Pg. 68 / 84
12 de enero de 2012
<ejb-name>
o Especifica el nombre del EJB que aloja el mtodo.
<method-intf>
o Es opcional y especifica la interfaz donde se ubican los mtodos. El valor
puede ser Home, Remote, Local LocalHome. Si se omite, los mtodos
de todas las interfaces deben especificarse.
<method-name>
o Es el nombre de un mtodo o *, que indica todos los mtodos.
<method-params>
o Es opcional y contiene una lista de tags <method-param>. Si mltiples
mtodos tienen el mismo nombre con diferentes parmetros, se puede
especificar el prototipo del mtodo.
o No se puede usar con *.
Valores para el tag <trans-attribute>
El tag <trans-attribute> puede tener uno de estos seis valores:
Never: Especifica que el EJB no puede ser invocado en el contexto de una

transaccin.
NotSupported: Provoca que las transacciones se suspendan durante la ejecucin

de EJBs.
Supports: Implica que el EJB se incluir en cualquier transaccin iniciada por el

cliente.
Required: Fuerza al EJB a ejecutarse en una transaccin iniciada por el cliente o

el contenedor.
RequiresNew: Fuerza al EJB a ejecutarse en una nueva transaccin iniciada por

el contenedor.
Mandatory: Obliga al cliente a pasar una transaccin global al EJB.
Cada valor indica el comportamiento que el contenedor debe adoptar cuando los
mtodos que generan, o estn expuestos a, transacciones son invocados. Cada
atributo indica qu hacer con una transaccin iniciada por un cliente y si debe
iniciarse una nueva transaccin.
Estos seis atributos de transaccin generan un gran nmero 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 <transaction-isolation>. Este tag

contiene dos cosas: el nivel de aislamiento y los mtodos que aplican en este nivel.
Este tag puede repetirse tantas veces como sea necesario.
Pg. 69 / 84
12 de enero de 2012
Los cuatro niveles de aislamiento disponibles son:
TRANSACTION_READ_UNCOMMITTED: Operaciones dirty reads, non-

repeatable reads, y phantom reads estn permitidas. Este es el nivel de
aislamiento ms 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 non-
repeatable 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 ms restrictivo.
<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 diseo
La configuracin de las transacciones pueden tener un gran impacto en el

rendimiento.
Muchas transacciones muy atmicas generan un trfico excesivo de
transacciones y pueden provocar la satuacin de los resource managers.
Transacciones que actualizan mutitud de registros pueden bloquear a otros
clientes accediendo a los mismos recursos.
Como buena prctica, puede tratarse de crear un bean de sesin que a travs del
patrn fachada o facade envuelva o agrupe mltiples invocaciones a mtodos
EJB para eliminar la acreacin de mltiples transacciones.
Todas las consideraciones de diseo estn orientadas a la reduccin del nmero de

transacciones y asegurar que el alcance de cada transaccin es a travs de la menor
cantidad de recursos posibles.
Finalmente, es importante asegurarse de limitar las transacciones, por ejemplo, en

una peticin Web, y no permitir que que las transacciones abarquen peticiones que
tengan relacin con el control o el flujo Web.
Timeout de transacciones
Veamos ahora las caractersticas del mecanismo de timeout dentro del control
transaccional:
Evitan que los recursos permanezcan innecesariamente ocupados por perodos

largos, asegurando que la transaccin nunca incluye la entrada de usuario.
Aseguran que las transacciones provocan bloqueos de filas en la base de datos del
menor tiempo posible.
Pg. 70 / 84
12 de enero de 2012
Para configurar el timeout de transaccin es necesario modificar el fichero weblogic-

ejb-jar.xml, tal como se muestra a continuacin:
<transaction-descriptor>
<trans-timeout-seconds>20</trans-timeout-
seconds>
</transaction-descriptor >
Pg. 71 / 84
12 de enero de 2012
Best Pratices para clustering
El Clustering es un grupo de WebLogic Servers que actan 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 prctica 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 aplicacin 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 replicacin 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 estra formado por diversos servidores de un mismo dominio, aunque no

es obligatorio que todos los servidores pertenezcan a una cluster. Por regla general,
stos estn precedidos de frontales, bien balanceadores bien servidores proxy, que se
encargan de dirigir la carga de las peticiones a todos los elementos del clster 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 nmero de
componentes que lo formen. A este conjunto de tcnicas se recogen bajo el balanceo
de carga.
El desafo 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 varan 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 reenva
peticiones HTTP a esas instancias utilizando la estrategia round-robin.
Pg. 72 / 84
12 de enero de 2012
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 clster gracias a una monitorizacin activa de cada uno de los
elementos que lo forman.
Como ejemplo de esta monitorizacin, podemos comentar la monitorizacin de las

conexiones a travs de sockets entre los elementos del cluster. Si un servidor se
conecta a uno de sus iguales en el clster y comienza a transmitir datos a travs 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
clster.
Arquitectura bsica de un clster
La arquitectura bsica recomendada de un cluster de Weblogic Server combina

todos los niveles de las aplicaciones web, es decir, HTTP esttico, capa de
presentacin y capa de negocio, en un mismo clster.
La arquitectura bsica tiene algunas ventajas claras:
Fcil administracin, ya que un clster simple al alojar todos los elementos,

pginas HTTP estticas, servlets y EJBs, se pueden configurar, desplegar y/o
eliminar objetos y aplicaciones web de forma atmica, usando, por ejemplo, la
consola de administracin.
Balanceo de carga flexible, el uso de balanceo de carga hardware en un cluster

WebLogic Server permite el uso de polticas avanzadas de balanceo de carga
para el acceso a contenido tanto dinmico como esttico.
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 mnimo de polticas de seguridad respesto a los firewalls.
Mediante una arquitectura de niveles combinada como la recomendada, se

satisfacen las necesidades de la gran mayora de aplicaciones web.
Arquictura multi capa de un clster
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
esttico y dinmico HTTP y el segundo para servir objetos de tipo EJBs en clster.
La arquitectura multi capa proporciona las siguientes ventajas:
Balanceo de carga en mtodos EJBs, ya que mediante el alojo de servlets y EJBs

en clusters separados, las llamadas a mtodos desde los servlets a los EJBs se
pueden balancear en mltiples servidores.
Pg. 73 / 84
12 de enero de 2012
Mejor balanceo de carga en el servidor, ya que al separar los niveles de

presentacin y de negocio, donde residen los objetos en cluster, se proporciona
ms opciones para distribuir la carga de las aplicaciones. Por ejemplo, si la
aplicacin accede a contenido HTTP y servlets ms frecuentemente que a
contenido servido a travs de EJBs, se pueden usar una mayor cantidad de
instancias de WebLogic Server en el nivel de presentacin del cluster
minimizando el nmero de servidores que alojan los EJBs.
Disponibilidad ms 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
clster falla, la capa de presentacin podr reencaminar la peticin a otro
miembro del cluster, y por tanto continuar de forma transparente.
Mayor seguridad, ya que al separar las capas de presentacin y negocio en dos

clsteres independientes, se pueden establecer polticas de seguridad y de
firewalling para cada una de las dos zonas, creando un DMZ en la zona de
presentacin 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 localizacin, 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 clsteres 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 clster distantes. Esto es
posible gracias a la replicacin sncrona de un clster 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
Bsicamente 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 travs de proxy plug-ins.
Consideracin para balanceadores de carga por hardware
A continuacin se enumeran algunas consideraciones a tener en cuenta durante la

configuracin de Weblogic Server sobre balanceadores de carga hardware.
Passive cookie
El mecanismo de persistencia a travs de passive cookie permite a Weblogic Server

crear una cookie que contiene un parmetro de sesin que a travs del balanceador
de carga llega al cliente.
Pg. 74 / 84
12 de enero de 2012
En el caso de uso de balanceadores de tipo hardware es obligatorio la configuracin

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 replicacin en memoria.
Esta cookie posee el siguiente formato:
Una cadena de texto con el valor de la session ID ms un byte como carcter

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 sern
sobreescritas o modificadas. En es caso, no es necesario ninguna configuracin extra
adems 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

informacin que circula entre los clientes y el clster a travs de una cookie en texto
plano que mantiene la correspondencia entre el cliente y el servidor dentro del
clster.
Replicacin de sesin
Componentes Web como servlets o pginas JSP mantienen datos de clientes en
instancias del objeto HttpSession. Por tanto, si deseamos tener la capacidad de alta
disponibilidad, esta informacin tiene que ser compartida por todos los nodos del
clster.
Para ello las instancias de HttpSession puede ser replicada a travs de la replicacin
en memoria o in-memory replication, persistencia en file system o persistencia en
base de datos
Replicacin basada en memora

En el caso de la replicacin basada en memora 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 clster, 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 comunicacin necesarios para la replicacin

de un objeto realizndose entre parejas de servidores y no a travs del clster
completo.
Pg. 75 / 84
12 de enero de 2012
Persistenca basada en JDBC
En el caso de la replicacin basada en persistencia JDBC, es necesaria una base de

datos que almacene la informacin de los objetos de tipo HttpSession.
Una vez configurado, cada una de los managed server que forman el cluster usarn
la misma configuracin para crear el pool de conexiones que le permita acceder a la
informacin compartida por la base de datos.
En esta situacin, si por ejemplo, un servlet crea un objeto de sesin, ste almacena la
informacin en la base de datos. Las siguientes peticiones del cliente, sea al miembro
del clster que sea, podrn manejarse de igual forma, ya que todos tiene acceso a la
informacin almancenada.
Este mecanismo posee una mejor capacidad de failover dado que cualquier servidor
puede resolver y atender cualquier peticin desde los clientes, pero por el contrario,
tiene una reduccin significativa de rendimiento al tener que sincronizar cualquier
cambio con la base de datos.
Persistenca basada en file system compartido
Finalmente, la persistencia de sesin basada en file system parte de la capacidad de

ste de ser compartido a nivel de acceso por todos los miembros del clster.
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 caractersticas de failover pero

tambin presenta problemas de rendimiento, especialmente en la sincronizacin de
las escrituras y lectura de todos los miembros del clster.
Configuracin de los tipos de replicacin
Replicacin de tipo In-memory:
<session-descriptor>
<persistent-store-type>replicated</persistent-store-type>
<persistent-store-type>replicated_if_clustered</persistent-
store-type>
Replicacin de tipo File System:
<persistent-store-type>file</persistent-store-type>
<persistent-store-dir>Directory Path</persistent-store-dir>
Pg. 76 / 84
12 de enero de 2012
Replicacin de tipo JDBC:
<persistent-store-type>jdbc</persistent-store-type>
<persistent-store-pool>Data Source Name</persistent-store-
pool>
Pg. 77 / 84
12 de enero de 2012
Best practices para Work Managers
Weblogic Server usa un mecanismo de pool de hebras nico que se adapta de

manera automtica para maximizar la productividad del sistema. A este proceso se
le conoce como mecanismo de self-tuning.
En este proceso, los queue monitor evalan la carga del sistema a travs del tiempo y
as como informacin histrica para ajustar el valor del nmero de hebras necesario,
incrementando o decrementando segn 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 mtricas de rendimiento internas,
como el tiempo empleado en ejecutar una peticin o el ratio de entrada y salida de
las peticin al pool de hebras.
De esta forma se hace ms sencillo para los administradores ajustar la cantidad de

recursos necesarios y se reduce, en general, las tareas de monitorizacin y ajuste de
colas configuradas por ellos.
Default Work Manager
Weblogic Server, por defecto, usa una nica cola de ejecucin basada en prioridades
donde todas las aplicaciones desplegadas tienen la misma prioridad de ejecucin.
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 tambin llamado
defualt. En l, el tamao del pool de hebras puede ser configurado tanto es su lmite
mximo como en su lmite mnimo.
Clases de tipo Request
Los adminsitradores puede determiner una serie de guas y asociarla a una o ms

aplicaciones o a un componente en particular. Weblogic Server usar estas guas
para realizar la asignacin del trabajo pendiente.
Las clases de tipo Request permite planificar el trabajo en base a la prioridad. Hay
que tener en cuenta que bsicamente 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 aplicacin referenciando el nombre del
componente en descriptor de despliegue. O bien puede crear un work manager que
encapsule estos componentes y referenciar a ste tambin en el descriptor de
despliegue.
Pg. 78 / 84
12 de enero de 2012
Clases de tipo Fair Share Request
Tal como hemos comentando en los work managers configurados como fair share, la
gestin se basa en prioridades. Y aunque todas las aplicaciones tiene por defecto la
misma prioridad, sta puede cambiarse de forma, que una aplicacin 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 ejecucin. El work

manager para el modulo A indicar una fair-share-request-class de 90, mientras que
el mdulo 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>
<name>high_priority</name>
<fair-share>90</fair-share>
</fair-share-request-class>
<fair-share-request-class>
<name>low_priority</name>
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 clculos necesarios para asegurar que el
tiempo de respuesta tolerable mediante la subtraccin 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 peticin proporcional al tiempo de
espera indicado. Veamos un ejemplo, si Weblogic Server ejecuta dos mdulos, A y B,
y deseamos un ratio de 1:8 entre ellas, usaremos la siguiente configuracin:
<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>
Clases de tipo Context Request
Este tipo de clases permite asignar una clases de tipo de request en base a una valor
de la peticin 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>
<name>simple_context</name>
Pg. 79 / 84
12 de enero de 2012
<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 mximo y mnimo de hebras que se crear para ejecutar las peticiones.
El nmero 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
Resctriccin Maximum Threads

Esta restriccin limita el nmero mximo de hebras que concurrentemente ejecutan
este tipo de peticin.
Las opciones de configuracin son las siguientes:
Name: Nombre de la restriccin.

Count: Nmero de hebras, por defecto -1.
Data Source: Opcionalmente, el nombre de la connection pool de donde se
tomar el valor mximo.
<max-threads-constraint>
<name>max_threads</name>
<count>10</count>
<connection-pool-name></connection-pool-name>
</max-threads-constraint>
Resctriccin Minimum Threads

Esta restriccin limita el nmero mnimo de hebras que concurrentemente ejecutan
este tipo de peticin.

<min-threads-constraint>
<name>min_threads</name>
Pg. 80 / 84
12 de enero de 2012
<count>1</count>
</min-threads-constraint>
Resctriccin Capacity
Este tipo de restriccin permite que el servidor rechace peticiones en caso de que se
alcance el lmite 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 lmite
de forma individual como de forma global.
Clases y restricciones de tipo Referencing
Un work manager puede definirse mediante la encapsulacin de una clase de tipo

request y una o ms restricciones.
Name: Nombre de la restriccin o de la clase.
<work-manager>
<name>priority_work_manager</name>
<name>very_high_priority</name>
<name>min_five_Threads</name>
<count>5</count>
</work-manager>
Global-Level Work Managers
Este tipo de work managers, como su propio nombre indica, afecta a todos los
mdulos y aplicaciones desplegadas en el servidor, y pueden crearse tango con la
consola de administracin como directamente sobre el fichero config.xml.
<self-tuning>
<name>HighFairShare</name> <target>mainserver</target>
Pg. 81 / 84
12 de enero de 2012
<name>MoreThreads</name> <target>mainserver</target>
<count>20</count>
<connection-pool-name></connection-pool-name>
<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 restriccin. A
partir de ese momento, el work manager las usar para priorizar la carga de trabajo.
Work Manager a nivel de aplicacin
Este tipo de work manager, aplican exclusivamente sobre las aplicaciones o modulos
a los que se le asocia a travs del fichero de despliegue weblogic-
application.xml tal como se indica a continuacin:
<weblogic-application>
<name>app_max_threads</name>
<count>10</count>
<name>app_min_threads</name>
<count>5</count>
</min-threads-constraint>
<work-manager>
<name>AppScopedWorkManager</name>
</work-manager>
</weblogic-application>
Work Managers a nivel de aplicaciones Web

Este tipo de work managers est exclusivamente disponibles para aplicaciones de
tipo Web a travs del fichero de polticas, weblogic.xml.
<weblogic-web-app>
<wl-dispatch-policy>LowPriority</wl-dispatch-policy>
<work-manager>
<name>LowPriority</name>
<name>LowFairShare</name>
Pg. 82 / 84
12 de enero de 2012
<name>LessThreads</name>
<count>2</count>
</work-manager>
</weblogic-web-app>
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 parametrizacin que se
ndique, aunque tambin pueden usarse para prevenir la sobrecarga de los managed
servers.
Max Stuck Thread Time, es el nmero 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 nmero de hebras en estado stuck para que el servidor
sea transladado al estado FAILED.
En el ejemplo siguiente se muestra la configuracin para un work manager con 5

hebras en estado stuck mas de 60 segundos.
<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>
Colas de ejecucin (Execute queues)
Retrocompatibilidad
Desde la versin 10 de Weblogic Server se prove de la posibilidad de usar la

retrocompatibilidad de las colas de ejecucin con el fin de facilitar las tareas
derivadas de las migraciones desde versiones anteriores.
Esta retrocompatibilidad permite que:
los work managers configurados se conviertan a execute queues en tiempo de

ejecucin por parte del servidor.
El nmero de hebras de una execute queue se base en una restriccin o
constraint.
Y que en caso de que un work manager no implemente alguna restriccin, se use
la global default execute queue.
Pg. 83 / 84
12 de enero de 2012
Para que ello sea posible, es necesario realizar uno de los dos cambios siguientes:
Usar la opcin siguiente en la linea de comando de los servidores:

-Dweblogic.Use81StyleExecuteQueues=true
Aadir la siguiente clusula al fichero de configuracin config.xml:

<use81-style-execute-queues>true</use81-style-execute-
queues>
Pg. 84 / 84

InfV5 JASAS WLS BusinessLayer BestPractices V310

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

InfV5 JASAS WLS BusinessLayer BestPractices V310

Cargado por

Copyright:

Formatos disponibles

Oficina de Calidad

Subdireccin de Tecnologas de la Informacin

Best practices de desarrollo sobre

Fecha Autor Versin Notas

13 de Enero de 2011 Emilio Nestal 2.1.0 Versin inicial

Jonathan Ortiz Advanced Support Engineer

Copia Nombre Empresa

1 Subdireccin de Tecnologas de la Servicio Andaluz de Salud, Junta de

CONTROL DE CAMBIOS ......................................................................................................................... 5

Beans de entidad (Entity beans) ...................................................................................................... 60

1 No se realizan cambios en esta versin

Estas recomendaciones estn encaminadas a minimizar los posibles problemas de

Finalmente, este documento tambin recoge una serie de conceptos de componentes,

Objetivos de este documento

Esta gua contendr tanto prcticas recomendadas como prcticas a evitar y se

Este documento se centra principalmente en las versiones Oracle WebLogic Server

El objetivo de esta gua de buenas prcticas tiene varios objetivos:

Aprovechamiento de las caractersticas del producto

Facilitar la implantacin y modificacin del aplicativo en produccin con

Best practices de desarrollo sobre Weblogic Server

Best Practices para JDBC

La independencia de plataforma es una caracterstica inherente de Java conseguida

Java proporciona un amplio soporte para la gestin de objetos remotos a travs de su

JDBC se ha convertido en una API para el acceso a cualquier tipo de forma de

Two-tier, donde el cliente se comunica directamente con la base de datos.

Los drivers Two-tier se usan por un cliente, independientemente de qu cliente

En un driver three-tier, WebLogic Server acta como capa intermedia,

El grfico anterior, muestra cmo las aplicaciones pueden conectarse directamente a

El primer tipo de driver es el puente JDBC-ODBC. El programa Java accede a la base

El driver de tipo 3, implementacin multi-capa, utiliza un servidor de red para

Consideraciones sobre los drivers JDBC

Un driver de Tipo 2 no es necesariamente ms rpido.

Esto ahorra a las aplicaciones la sobrecarga de la creacin de conexiones. Incluso el

El balanceo de carga puede incluso incluir un crecimiento y una reduccin dinmica

El grfico muestra que el servidor de aplicaciones aloja el pool de conexiones y que

Tamao del Pool de Conexiones

Capacidad Inicial: El nmero de conexiones fsicas a crear cuando se crea un

Capacidad Mxima: El nmero mximo de conexiones fsicas que el pool de

Incremento de Capacidad: El nmero de conexiones creadas al aadir nuevas

WebLogic Server reduce peridicamente el pool de conexiones a su capacidad inicial

El parmetro Shrink Frequency se usa para especificar el nmero de segundos a

Test Connection On Reserve: Habilita a WebLogic Server para hacer un test

El row prefetching mejora el rendimiento al cargar multiples filas del servidor al

Tamao del Row Prefetch: Si est habilitado el row prefetching, especifica el

El comportamiento de Weblogic Server en cuanto a la funcionalidad de cacheo de

parmetro define el algoritmo usado para mantener las sentencias preparadas

Las opciones son:

FIXED, es decir, se cachean las N primeras sentencias, ignorando el resto

Para determinar el tamao de la cach, Weblogic Server usa el parmetro Statement

Dos caractersticas adicionales para esta caracterstica:

Cada conexin 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

Un efecto de esta configuracin, es que se reduce la potencial contencin que se crea

Este tipo de situaciones, se pueden obtener benecificios si:

Las combinamos de forma apropiada podremos mejorar el rendimiento.

La gestin de la transaccionalidad de una aplicacin pueden requerir un esfuerzo

En el caso de las bases de datos, las transacciones consumen y mantienen muchas

Al deshabilitar el auto-commit e indicando explcitamente los lmites de las

La API de JDBC proporciona tambin el mtodo Connection.getAutoCommit() que

El nivel de aislamiento de una transaccin suele definirse como el balanceo de las

La integridad de los datos frente a

En base a este balanceo se establecen cuatro nieveles transaccionales:

Como veremos, cuando ms alta es la integridad de los datos, ms lento es el acceso.

Pero a qu nos referimos con integridad? Cuando hay un problema con la