Consideraciones de programación del Data Mediator Service de EJB
Cuando empieza a escribir las aplicaciones para aprovechar el Data Mediator Service (DMS) de EJB (Enterprise JavaBeans) incluido en el producto, tenga en cuenta los elementos siguientes.
Modelo de programación de EJB
Sólo un subconjunto del modelo de programación de EJB se admite en el Data Mediator Service de EJB.
- Cuando utiliza parámetros de colección de EJB para recuperar datos de instancias de EJB,
o bien, cuando utiliza applyChanges para actualizar instancias de EJB:
- El DMS de EJB utiliza interfaces locales para enterprise beans. Las llamadas a Getter y setter para campos CMP (persistencia gestionada por contenedor) deben promoverse a la interfaz local, así como los métodos EJB utilizados en expresiones de consulta.
- Para que el mediador cree un EJB, debe haber un método create que utiliza la
clase de clave primaria como el único método de argumento definido en la factoría de EJB. Si no existe dicho método, debe proporcionar un adaptador que maneje la operación create. Además, la interfaz EJBLocalHome definida para el EJB debe incluir
(además del método create) el método siguiente:
findByPrimaryKey(<clase de clave>) remove (java.lang.Object) create (<key class>)
- Cuando invoca directamente el método applyChanges en la base de datos, se produce lo siguiente:
- Omite la actualización del contenedor. Debería forzar una renovación lo antes posible mediante la terminación de la transacción y el uso de opciones de memoria caché de contenedor adecuadas.
- Omite el mantenimiento de CMR (relación gestionada por contenedor) de EJB. Debe confiar en el RI de la base de datos para mantener esas relaciones no recuperadas en el DataGraph.
- Los campos CMP deben ser los tipos permitidos. Consulte el apartado Sintaxis de consulta del mediador EJB para obtener una lista de esos tipos.
- No se admiten los campos CMP de tipos definidos por el usuario que utilizan convertidores/compositores de EJB.
La tabla siguiente muestra limitaciones del modelo de programación de EJB que no se admiten en el DMS de EJB.
Recuperar directamente de la base de datos | Recuperar del contenedor de EJB | Actualizar directamente en la base de datos | Actualizar mediante EJB | |
---|---|---|---|---|
Herencia de persistencia de EJB | No | No | No | No |
Campo cmp de EJB con convertidor | No | Sí | No | Sí |
Transaccional
- Todas las llamadas del mediador, incluida create, deben realizarse dentro del ámbito de transacciones, ya sean transacciones de usuario o de contenedor. Las distintas llamadas del mediador, incluidas create, getGraph y applyChanges, no tienen que realizarse dentro de la misma transacción. De hecho, la mayoría de las llamadas se realizan en transacciones separadas.
Intento de acceso
- Cuando la consulta del mediador hace referencia a un EJB mediante un nombre esquema abstracto (ASN), los datos se recuperan directamente de la base de datos. El intento de acceso y nivel de aislamiento utilizados en la conexión de origen de datos se corresponden con el intento de acceso especificado en el perfil de aplicación para el intento de acceso de consulta dinámica EJB. Se recomienda que defina un intento de acceso optimista para la aplicación ya que un DataGraph está diseñado para que se utilice en un modelo de programación desconectado.
- Cuando el mediador está recuperando datos utilizando una colección de EJB, el intento de acceso especificado en el perfil de aplicación se utiliza si el EJB necesita ser activado.
- Durante applyChanges, el control de simultaneidad optimista
se utiliza para verificar ciertos campos del DataObject antes de
aplicar los cambios a la base de datos. Las actualizaciones generalmente
se procesan utilizando una transacción distinta de la recuperación. Por lo tanto, para evitar actualizaciones perdidas, es necesario
verificar que otra transacción no haya actualizado los datos. Al definir
la correlación de EJB con RDB, puede especificar uno o más campos como
predicados optimistas. Los campos se utilizan para la verificación
comparando el valor de base de datos actual con el valor antiguo de los registros de cambios de DataGraph. Si la verificación se
realiza satisfactoriamente, el valor actual de los campos se escribe en la
base de datos. Si la
comparación devuelve false y no se puede realizar la actualización, se produce una excepción. Todo esto se realiza en una única sentencia de actualización con
predicados adicionales añadidos como se muestra en el siguiente ejemplo. El
campo optimisticPredicate es myColumn1.
update myTable set myColumn1="new value1", myColumn2="new value2"where myKey="key value" and myColumn1="old value1"
- Cuando se realiza applyChanges a través del contenedor de EJB, los valores actuales de los enterprise beans se comparan con los valores anteriores de los campos de predicados optimistas. Si los valores son distintos se produce una excepción.
- Siempre que haya definido uno o más campos EJB como optimisticPredicates, para que se actualice el SDO, debe recuperarse uno de los campos optmisticPredicate como mínimo en el objeto de datos. De lo contrario, applyChanges devuelve una excepción. El campo debería actualizarlo o bien el interlocutor o un desencadenante de base de datos – el mediador no incrementa ni establece automáticamente el campo.
- No se verifican todos los campos, sólo aquellos campos marcados como optimisticPredicate en la correlación EJB-RDB.
- Tenga en cuenta que la herramienta de correlación de EJB permite la posibilidad de campos que no sean optimisticPredicate. En este caso el mediador realizar actualizaciones sin ninguna verificación.
- Las operaciones de creación o supresión no utilizan los campos de predicados optimistas.
- Al aplicar cambios en las instancias de EJB, es posible que primero se tenga que activar el EJB. En este caso, se aplica el intento de acceso adecuado asociado con los métodos de EJB. Se recomienda que ejecute applyChanges en un perfil que tenga el intento de acceso pesimista, de lo contrario, la lógica se simultaneidad optimista se invoca dos veces: la primera vez al copiar los valores de objeto de datos en el EJB, y la segunda cuando el gestor de persistencia compara los valores antiguos de los valores de campos EJB con el registro de base de datos.
- El intento de acceso utilizado por el mediador cuando se recupera directamente de la base de datos es el intento de acceso predeterminado definido para el EJB nombrado en la primera sentencia de consulta.
Procedimientos recomendados
- Puede llamar a getGraph en una instancia del mediador, actualizar el DataGraph devuelto y después llamar a applyChanges en una instancia distinta del mediador. No obstante, mientras que no necesitan la misma instancia del mediador, necesitan la misma conformación de consulta. La conformación de consulta es el número y orden de las sentencias de consulta, los campos y las relaciones especificadas en las cláusulas SELECT y FROM, etc.
- Evite las llamadas repetidas a createMediator si es posible. Utilice consultas parametrizadas y utilice getGraph para pasar valores de parámetro distintos.