Propagación de transacciones de Oracle entre C++ y Java

Question

Tenemos una aplicación de C++ existente que vamos a reemplazar gradualmente con un nuevo sistema basado en Java. Hasta que hayamos reimplementado completamente todo en Java, esperamos que C++ y Java tengan que comunicarse entre sí (RMI, SOAP, mensajería, etc., no lo hemos decidido).

Ahora mi gerente piensa que necesitaremos los lados Java y C++ para participar en la misma transacción Oracle DB. Esto está relacionado con el problema habitual de transacción distribuida, pero es diferente de tener un proceso único que coordine 2 recursos transaccionales, como un DB y una cola de mensajes.

Creo que propagar una transacción entre los procesos es una idea terrible desde el punto de vista de la performance y la estabilidad, pero aún así se me pedirá una solución.

Estoy familiarizado con las transacciones XA y he trabajado un poco con JBoss Transaction Manager, pero mi Google no ha encontrado nada bueno en la propagación de una transacción XA entre 2 procesos.

Estamos utilizando Spring en el lado de Java y su documentación establece explícitamente que no proporcionan ninguna ayuda con la propagación de transacciones.

No estamos planeando utilizar un servidor Java EE tradicional (por ejemplo: IBM Websphere), que puede tener soporte para propagación (no es que pueda encontrar documentación definitiva).

Cualquier ayuda o consejos sobre soluciones es muy apreciada.

Answer 1

Hay an example on Laurent Schneider's blog de usar el paquete DBMS_XA dentro de Oracle para permitir que varias sesiones funcionen en la misma transacción. Por lo tanto, sería posible tener sesiones Java y C++ participando en la misma transacción sin necesidad de ningún tipo de coordinador adicional.

Como alternativa, puede considerar el uso de Workspace Manager. Originalmente, se diseñó para admitir transacciones extremadamente largas (es decir, manipular muchos datos espaciales para un desarrollo propuesto). Esencialmente, puede crear un espacio de trabajo, que en su caso sería más o menos equivalente a una transacción con nombre. Tanto el código de Java como el de C++ podrían ingresar a ese espacio de trabajo (desde sesiones separadas) y ambos podrían manipular y confirmar datos en ese espacio de trabajo. Cuando se completa la transacción, puede fusionar el espacio de trabajo en el espacio de trabajo EN VIVO, lo que equivale a realizar una confirmación en una transacción normal.

Por otro lado, estoy totalmente de acuerdo con su evaluación inicial de que la coordinación de transacciones entre procesos es muy probable que sea una mala idea desde el punto de vista del rendimiento, la estabilidad, la simplicidad y el mantenimiento. Por otro lado, bien puede ser un requisito comercial legítimo dependiendo de cómo se va a retirar el código C++ (es decir, si es posible reemplazar el código de tal manera que las transacciones pueden ser exclusivamente Java o exclusivamente C++)

Answer 2

Creo que JBoss Transaction Manager admite la propagación de 2pc tx en las llamadas al servicio web. Podría, supongo, integrar sus sistemas de esa manera, pero el rendimiento apestaría.

Answer 3

He estado utilizando Hazlecast bloqueos de memoria distribuida y de mensajería para resolver algunos de estos problemas, sin embargo, el uso de una herramienta de este tipo requeriría redisignar su software en aquellas partes donde toque los mismos datos. C++ cliente docs here Cliente Java here

Oracle también tiene un producto similar llamado Oracle Coherence que puede ayudarle, consulte locking en la guía de desarrollo.

También la base de datos contiene un sistema MQ llamado Oracle Streams Advanced queueing (colas transaccionales persistentes) que pueden ayudarle en algunas situaciones. Oracle AQ se integra bien con los desencadenadores de Oracle.

Además existe la Database Change Notification que pueden ayudarle a actualizar cachés o llame a los procesos de cambios, esto se puede utilizar junto con el Optimistic Offline Lock pattern.

Ver también Software transactional memory

Apache Zookeeper también le puede ayudar con locking distribuido.