Prioridad de confirmación para recursos transaccionales
Puede especificar el orden en que se procesan los recursos transaccionales durante el proceso de confirmación en dos fases.
- La optimización de la confirmación en una fase se produce más a menudo.
- Se resuelven los problemas potenciales causados por el aislamiento de las transacciones.
Para controlar el orden en que se procesan los recursos transaccionales durante el proceso de confirmación en dos fases, especifique la prioridad de confirmación de un recurso definiendo el atributo de prioridad de confirmación en una referencia de recursos. Cuanto mayor sea la prioridad de confirmación, antes se procesará el recurso. Por ejemplo, si un recurso tiene un prioridad de confirmación de 10, se procesa antes de un recurso con una prioridad de confirmación de 1. El valor de la prioridad de confirmación es del tipo int y puede oscilar entre -2147483648 y 2147483647.
Si no especifica un valor de prioridad de confirmación, se asigna el valor predeterminado cero al recurso y se utiliza al solicitar recursos durante la ejecución. Si dos o más recursos se configuran con la misma prioridad, incluida la prioridad por omisión, se procesan en un orden no especificado entre sí.
Puede especificar el atributo de prioridad de confirmación en una referencia de recurso mediante las herramientas de Rational Application Developer. Para obtener información detallada, consulte el Information Center de Rational Application Developer. El componente de la aplicación debe disponer de un descriptor de despliegue. No es posible especificar este atributo si se ha utilizado una anotación.
Optimización de la confirmación en una fase
En una transacción con una confirmación en dos fases, si cada recurso excepto el último listado en los votos de transacción de sólo lectura, que indica que esos recursos no están interesados en el resultado de la transacción, puede realizarse una confirmación en una fase. Esto significa que no es necesario que el servicio de transacciones almacene información de recursos y transacciones que necesitará para retrotraer una confirmación en dos fases y, por lo tanto, el rendimiento mejora.
Puede controlar el orden en que se procesan los recursos transaccionales durante la confirmación en dos fases, por lo que puede procesar los recursos que es más probable que vote primero como de sólo lectura. Por consiguiente, aumenta la probabilidad de que se pueda producir una confirmación en una fase.
![[z/OS]](../images/ngzos.gif)
Aislamiento de la transacción
Cuando hay recursos implicados en una transacción global, las actualizaciones que se llevan a cabo como parte de una transacción no son visibles fuera de la transacción hasta que se confirme la transacción, es decir, esos recursos están aislados. Este aislamiento puede causar problemas con otros componentes de aplicaciones que actúan sobre las actualizaciones después de que se confirmen. Por ejemplo, el proceso adicional puede fallar, o hacerlo de forma intermitente, porque las actualizaciones dependen del orden y del tiempo. Este problema no se produce con el trabajo de mensajería del bus de integración de servicios en WebSphere Application Server, pero puede ser un problema para otros proveedores de mensajería, por ejemplo, WebSphere MQ.
Si especifica el orden en que se confirman los recursos transaccionales, los problemas causados por el aislamiento se resuelven para todos los sistemas transaccionales, no sólo los proveedores de mensajería y el bus de integración de servicios en particular.
El ejemplo siguiente describe cómo pueden producirse los problemas cuando no se puede especificar el orden en que se confirman los recursos transaccionales. Una aplicación actualiza una fila en una tabla de base de datos y, a continuación, envía un mensaje de JMS que desencadena el proceso adicional de la fila. Ambas acciones se realizan en la misma transacción global, por lo que están aisladas hasta que se confirman sus recursos respectivos. Si la actualización de la fila se confirma antes de enviar el mensaje, el proceso desencadenado por el mensaje puede acceder a la fila actualizada y procesarla. Si primero se confirma la acción de enviar el mensaje, esta acción puede desencadenar el proceso adicional de la fila antes de que la base de datos haya confirmado la actualización en la fila. En esta situación, la fila actualizada sigue aislada y no es visible, por lo que falla el proceso adicional de la fila.
Este problema puede ser más complicado porque depende del orden y del tiempo. Si la base de datos se confirma primero, el problema no se produce. Si primero se confirma la acción de enviar el mensaje, el problema puede producirse, pero depende de si el trabajo de base de datos se confirma antes de que el mensaje desencadene el proceso adicional de la fila. Por consiguiente, el problema puede ser intermitente, por lo que es más difícil identificar su causa.
Restricciones para versiones anteriores de WebSphere Application Server
Si especifica la prioridad de confirmación de un recurso, es decir, especifica cualquier valor excepto el valor predeterminado 0, se añade la prioridad de confirmación a las anotaciones asociadas en una sección de unidad recuperable. Esta sección del archivo de registro se reconoce en WebSphere Application Server Versión 7.0 o posterior, pero no en versiones anteriores del servidor de aplicaciones.
Por consiguiente, si una aplicación utiliza el atributo de prioridad de confirmación, no puede instalar esa aplicación en un clúster de versión mixta donde uno o más servidores del clúster están en versiones de WebSphere Application Server que son anteriores a la Versión 7.0.
Asimismo, si una aplicación que utiliza el atributo de prioridad de confirmación se instala en un clúster, no puede añadir subsiguientemente un servidor a dicho clúster si el servidor está en una versión de WebSphere Application Server que es anterior a la Versión 7.0.
Para obtener información general sobre las diferentes versiones del producto, consulte el tema "Visión general de la migración, la coexistencia y la interoperatividad".