Driver
De acuerdo con la documentación de los third-party drivers >> el de MS-SQL no se encuentra por defecto en WebLongi 10.3.4…
Pero ¿formará parte de los drivers type 4 de DataDirect (¿?) >>? Parece que, por lo menos para MS-SQL 2005, sí >>
Por lo tanto no será necesario instalar el driver JDBC que ofrece Microsoft >>
JPA 1
WebLogic 10.3.4 viene con dos implementaciones de JPA 1 : Kodo (default) o TopLink.
El primero – que estamos usando – es una extensión de OpenJPA >>
Basándose en esta documentación, nos podemos conectar a una fuente de datos con el javax.sql.DataSource de OpenJPA por medio de las propiedades propietarias en el persistence.xml
<?xml version="1.0" encoding="UTF-8"?> <persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"> <persistence-unit name="MiDB"> <properties> <property name="openjpa.ConnectionDriverName" value="weblogic.jdbc.sqlserver.SQLServerDriver"/> <!--no XA--> <property name="openjpa.ConnectionURL" value="jdbc:weblogic:sqlserver://servidor:1433;database=DB"/><!--nombre DB--> <property name="openjpa.ConnectionUserName" value="usuario"/> <property name="openjpa.ConnectionPassword" value="passwd"/> </properties> </persistence-unit> </persistence>
Sin embargo, no necesariamente es la mejor práctica distribuír los datos de conexión en la app… por seguridad – o por poolear conexiones o cosas así… (intuyo).
La otra es crear un DataSource desde la consola de administración de WebLogic.
Ésto es en Directorio Raíz > Orígenes de Datos > Nuevo > Orígen de datos genérico :
DataSource MSSQL
En el siguiente paso escogeremos el driver por defecto no XA
Driver MSSQL WebLogic 10.3.4
y después pa’lante no más – por ahora – hasta darle los datos de conexión y probar.
(Ni el equivalente XA ni el de Microsoft funcionan sin configuraciones adicionales en una instalación limpia de WebLongi)
Luego, hay que asegurarse que, como estamos haciendo una prueba de resource básico – dígase no-JTA – seleccionemos que el DS no Soporta Transacciones Globales :
de lo contrario, corremos el siguiente riesgo
org.apache.openjpa.util.StoreException: Cannot set auto commit to "true" when in distributed transaction.
(Dos DS sin Transacciones Globales: non-jta-datasource corre en ambos. Dos DS con Transacciones Globales: non-jta-datasource corre en ambos. Uno con y otro sin : non-jta-datasource se cae en el que tiene Transacciones Globales y corre en el que no.Queda demostrado positivamente.)
Finalmente, desde el persistence.xml, referenciaremos el DataSource con el tag non-jta-data-source
<?xml version="1.0" encoding="UTF-8"?> <persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"> <persistence-unit name="MiDB"> <provider>org.apache.openjpa.persistence.PersistenceProviderImpl</provider><!--!--> <non-jta-data-source>java:/nombreJNDI</non-jta-data-source> </persistence-unit> </persistence>
Ojo con el provider, que no es evidente que tiene que ser org.apache.openjpa.persistence.PersistenceProviderImpl (KODO es OpenJPA…), ni menos que tiene que estar antes que el jta-data-source
JTA
Si queremos que la persistencia participe de las transacciones JTA (manejadas por el contenedor) podemos referenciar el datasource con el tag jta-data-source
<jta-data-source>java:/nombreJNDI</jta-data-source>
Ésto puede funcionar aún cuando el driver que hayamos escogido no sea XA.
En Directorio Raíz > Orígenes de Datos > MiDataSource vamos a la pestaña Transacción y seleccionamos Soporta Transacciones Globales
DataSoure MSSQL con JTA
Nótese que por defecto viene con Confirmación en Una Fase. Ésto es relativo a la confirmación del éxito (commit o rollback) de una transacción JTA. Sé que sii el Data Source fuese XA, el tipo de confirmación necesariamente sería en Dos Fases. Ésto es, una primera fase en que el contenedor (en este caso, WebLogic) pregunta a cada fuente involucrada si vota por confirmar o revertir la transacción (si es que, por ejemplo, tuvo alguna excepción); una segunda fase en que, en base a este escrutinio, comanda a cada parte (porque en realidad, además de DS pueden ser colas JMS, etc.) para que o todas hagan commit o todas rollback.
De hecho vemos que arriba está la posibilidad de emular la Confirmación en Dos Fases. Pero si leemos la Ayuda de al lado dice
Con esta opción, la rama de transacción en la que se utiliza la conexión siempre se devuelve correctamente para la fase de preparación de la transacción. Esta opción ofrece beneficios de rendimiento, pero también supone riesgos para datos en algunas condiciones de fallo.
o sea que en el fondo siempre vota que sí se haga commit, por lo que supone un riesgo.
Por otra parte, la Ayuda de la Confirmación en Una Fase dice
Permite que las conexiones JDBC no XA participen en transacciones distribuidas mediante el procesamiento de transacciones de confirmación en una fase. Con esta opción, ningún otro recurso puede participar en la transacción global.
i.e. el DS es manejado por el contenedor (CMT) pero es el dictador de la transacción, por lo que no puede haber otros recursos – por lo menos en su transacción… para este caso, como no tengo más recursos, no hay problema con ésto.
Mejor opción si tenemos más recursos manejados por el contenedor en la transacción, es la de Registro de Último Recurso, en que, en el fondo, la base de datos es la última en votar. Así, si falla otro recurso igual hará rollback, pero si la base de datos falla hace Rollback con Confirmación en Una Fase y no espera la respuesta, mientras que los demás, como sí tienen Dos Fases, también hacen rollback. Hace sentido:
Con esta opción, la rama de transacción en la que se utiliza la conexión se procesa como el último recurso en la transacción y como una operación de confirmación de una fase. El resultado de la operación se escribe en un archivo log en el recurso mismo y el resultado determina el éxito o fallo de la fase de preparación de la transacción. Esta opción ofrece algunos beneficios de rendimiento con mayor seguridad de datos que la opción Emular Confirmación en Dos Fases.