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.

Si controla el orden en que se procesan los recursos transaccionales durante el proceso de confirmación en dos fases, tiene dos ventajas principales:
  • 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.

Habitualmente, para un recurso transaccional dado, se sabe el trabajo que se realiza durante la ejecución, por lo que, si puede controlar el orden en que se procesan los recursos en una transacción, puede aumentar la probabilidad de que se produzca una optimización de la confirmación en una fase.
[z/OS]config: Si utiliza el adaptador de recursos MQ con una especificación de activación, el servidor de aplicaciones no es capaz de optimizar las transacciones RRS para utilizar la confirmación de una fase. Utilice los puertos de escucha si necesita esta funcionalidad.

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".


Icon that indicates the type of topic Concept topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cjta_rescom
File name: cjta_rescom.html