12
May

Transacciones y bloqueos en Glassfish v3 con EJB3.1 y JPA2 (II)

persistencia2Continuo con mi proyecto de mega-artículo-tutorial-taladro sobre transacciones y bloqueos con JPA2 y EJB 3.1 en Glassfish v3.

En el artículo anterior, aprendimos a configurar base de datos y servidor para poder llevar a cabo este tutorial. En esta nueva entrega, aprenderemos a configurar nuestra aplicación para que pueda trabajar con estas tecnologías.

3. CREANDO NUESTRO PROYECTO EN EL IDE

Yo he utilizado Netbeans 6.8 como IDE para crear este ejemplo. No porque crea que sea el mejor entorno de trabajo, ni porque sea un fan de los productos de Oracle/SUN, sino porque es el que mejor integración nativa trae de serie con Glassfish v3. Bajo mi modesta experiencia -y llevo unos cuantos años en esto- el Servidor de Aplicaciones elegido puede condicionar totalmente vuestra arquitectura; y la integración, gestión y depuración del mismo, la elección de un IDE u otro. Podéis seguir este tutorial aunque utilicéis otro IDE, sólo tenéis que adaptar lo que se vaya haciendo a las peculiaridades de vuestro entorno de trabajo.

Para crear nuestro proyecto utilizaremos el wizard que se lanza desde la siguiente ruta de menú:

File >> New Project >> Java Web >> Web Application.

Se desplegará una primera interfaz donde se indicará el nombre del proyecto:

Interfaz de creación de proyecto

Interfaz de creación de proyecto (pulsa sobre la imagen para verla grandota)

La siguiente interfaz sirve para especificar el servidor con el que trabajará el proyecto, la versión de java utilizada y el contexto web que lo lanzará. Si sois unos vagos -como yo- habréis utilizado el Glassfish v3 que instala NetBeans para configurarlo como explique en el anterior artículo. Si, por el contrario, os dado por innovar, coleccionais todas las versiones del servidor o, en definitiva, os gusta hacer las cosas bien, puede que tengáis que añadir otro contexto de servidor mediante el botón “Add”. Aquí tenéis mi configuración:

Configurando sel servidor, versión de java y contexto

Configurando sel servidor, versión de java y contexto

La siguiente y última interfaz nos interrogará para saber si queremos incluir algún framework de trabajo como, por ejemplo, JSF en nuestro proyecto. Le diremos que “de momento, no gracias“. Bastante tenemos con nuestras transacciones (vamos por dos artículos… y lo que nos queda).

Una vez apretemos el botón de ‘Finish‘ habremos creado un esqueleto de proyecto donde se incluyen las librerías del JDK 1.6, de Glassfih v3 y, para pruebas, JUnit y el contexto embebido de Glassfsh.

4. CREANDO UNA UNIDAD DE PERSISTENCIA

Creado el proyecto, aparecerá en el explorador de la izquierda del interfaz un icono muy pituco que representa una bola del mundo (o algo así). Si pulsáis sobre el mismo con el botón derecho del ratón y seguís la siguiente ruta de menú New >> Persistence Unit, accederéis a un nuevo mundo de poder y sabiduría… y al wizard de creación de unidades de persistencia.

El wizard de creación de Unidades de Persistencia

El wizard de creación de Unidades de Persistencia

Aquí tenemos que pararnos durante un rato y explicar que es cada cosa y porque se elige una opción u otra. Al menos, si queremos enterarnos minimamente de que es cada cosa en vez de seguir el tutorial cual robots.

¿Sabemos lo que es una Unidad de Persistencia? Si, la respuesta es “si”, podéis pasar al siguiente párrafo. En caso contrario, os diré que el concepto de unidad de persistencia o persistence unit fue introducido por JPA1 y sirve para definir el conjunto de clases de entidad -que representan entidades de una base de datos- que serán gestionadas por nuestro contexto de persistencia o, lo que es lo mismo, los polvos mágicos que conseguirán que, al crear un objeto de tipo com.six.Boniato y persistirlo, se cree un nuevo registro en la tabla Boniato de nuestra Base de Datos. Además, contiene un  conjunto de metadatos que configuran el trabajo con dichos datos. Esos metadatos pueden incluir desde el nivel de traza con el que deseamos tracear el trabajo del motor de persistencia hasta los datos necesarios para crear una conexión directa a la base de datos y hacer que nuestra aplicación no dependa del registro de un datasource en el servidor de aplicaciones.

Las unidades de persistencia y sus atributos se definen en el fichero persistence.xml. Puede que hayais oído que este fichero se coloca en el directorio /META-INF de nuestra aplicación. Bueno, pues si pero no. No está de más leernos lo que nos dice la propia SUN sobre el tema. Son cuatro reglas, pero nos puede evitar numerosas y crípticas com.boni.CascotazoException con trazas similares al comportamiento de Matrix.

Lo primero que pide el wizard es un nombre con el que identificar a nuestra unidad de persistencia. Si sólo tenemos configurada una única unidad de persistencia, se seleccionará la misma como unidad por defecto. Si tenemos más de una -por ejemplo, una para desarrollo y otro para pruebas en un entorno de integración- podremos utilizar una u otra identificándolas a partir de su nombre.

Lo siguiente que pide el wizard es el proveedor de persistencia o Persistence Provider. Básicamente, la implementación de la API de JPA que deseamos utilizar. NetBeans incluye varias implementaciones pero, si queréis utilizar JPA2, la única opción que podéis elegir es EclipseLink.

El tercer dato que pide el wizard es la fuente de datos o Data Source con el que va a trabajar la Unidad de Persistencia. Podéis dejar vacío este campo y crear la unidad de persistencia sin Data Source asociado pero yo no os lo recomiendo. Eso obligaría a registrar en el fichero persistence.xml todas las propiedades -especificas para cada proveedor de persistencia- necesarias para crear localmente el Data Source y, lo que es peor, el tipo de transacciones siempre debería ser RESOURCE_LOCAL, no JTA. ¿Es eso malo? No tiene porque serlo, pero ¿por que restringir vuestra libertad de opción?.

Si aún así, queréis hacerlo, aquí tenéis dos buenos ejemplos de como hacerlo.

En el caso de que me hagáis caso y decidáis utilizar un Data Source, recordad que vais a desarrollar una aplicación para desplegar en el Glassfish v3 que configurasteis en el artículo anterior. El Data Source de JPA se corresponde con el Recurso JDBC de Glassfish. Yo configuré mi recurso con el nombre global JNDI jdbc/states, así que este es el nombre con el que voy a registrar mi Data Source en mi unidad de persistencia. Cuando despliegue la aplicación en Glassfish, el acceso a datos estará configurado automáticamente.

También podéis recrear el Data Source en NetBeans ¿Para qué? Para poder crear clases de entidad a partir de tablas, mediante wizards del IDE; validar que vuestro modelo se ajuste a vuestras clases, etc. Tener el Data Source de vuestro servidor de aplicaciones configurado en el IDE es guayabero, guayabero y, encima, bastante sencillo de implementar hasta bajo nivel, la conexión física. Os dejo una ruta gráfica:

PUWizardc

Como configurar un Data Source en NetBeans

Una vez creado (o no) el Data Source de la Unidad de Persistencia, encontramos en el wizard un checkbox que permite indicar si se desea trabajar con o sin JTA, o lo que es lo mismo, si queremos que el contenedor gestione las transacciones por nosotros o queremos meter mano y configurarlas a pelo Capello. La elección es vuestra pero, personalmente, me fio bastante mas del contenedor que de mi mismo. De hecho, me fio bastante mas de que el Atleti gane 10 años seguidos la Champions League de que yo no me deje alguna transaccion abierta donde no deba.

La gestión local de transacciones sólo se recomienda en casos muy específicos, donde se desea tener control de transaccionalidad intra-método de EJB.

Dependiendo de vuestra elección, se creará un jta-data-source, para trabajar con Data Sources gestionados con JTA, o un  non-jta-data-source, para los Data Sources que no trabajen con JTA.

La última opción que presenta el wizard es la estrategia de creación de tablas. Dependiendo de la estrategia seleccionada, el IDE intentará o no crear las tablas en vuestra base de datos si no las encuentra.

Finalmente, la configuración de mi wizard queda tal que así:

El New Persistence Unit wizard

El New Persistence Unit wizard

Una vez creada la Unidad de Persistencia, estamos preparados para crear código con JPA2, JTA, transacciones, bloqueos y hasta tirabuzones triples… pero eso lo veremos en la siguiente entrega.

De nuevo, nos hemos ido hasta cerca de las 1500 palabras, sobrepasando con mucho el máximo deseable para un artículo en un blog. Así pues, os emplazo a una tercera y espero que definitiva entrega… si aún os siguen quedando ganas de trabajar con EJB3.1 y JPA2 :)

DISCLAIMER

No tengo mucho feedback sobre esta serie de artículos, exceptuando las del ya mítico Dr. Arranz y mis secuaces tuiteros. Una sensación de tostón técnico invade todo mi ser, así que, si tienes algún consejo o sugerencia para mejorar la tercera entrega, no dudes en hacérmelo saber.

Artículos relacionados:

  1. Arquitectura de logging en Glassfish Aprende como funciona el sistema de registro o logging en...
  2. Transacciones y bloqueos en Glassfish v3 con EJB3.1 y JPA2 (III) Tercera parte del tutorial sobre como utilizar transacciones y bloqueos...
  3. Transacciones y bloqueos en Glassfish v3 con EJB3.1 y JPA2 (I) Un sencillo tutorial sobre como utilizar transacciones y bloqueos con...


free blog themes
free blog themes