Tengo un proceso que implica el envío de un mensaje JMS. El proceso es parte de una transacción. Si falla una parte posterior de la transacción, una parte posterior a una parte anterior que envió el mensaje, necesito cancelar el mensaje. Lo único que pensé fue configurar el mensaje de alguna manera para que no se recogiera durante un cierto período de tiempo, y si necesito deshacerlo, podría ir y cancelar el mensaje. Si no conozco los mensajes, no sé si la idea es posible. O, ¿hay una mejor idea? GraciasJMS rollback
Respuesta
Puede usar JMS y JTA (Java Transaction API) al mismo tiempo - see here. Al hacer eso, el envío de un mensaje JMS o el consumo de un mensaje recibido sucede de manera atómica como parte de la confirmación de transacción.
¿Qué significa esto? Si la transacción falla o se revierte, el mensaje "enviado" no se apaga y los mensajes "recibidos" no se consumen realmente. Todo gestionado para usted por su proveedor JMS y JTA.
Debe utilizar una implementación JMS que admita JTA. Parece que ya está usando transacciones, por lo que podría ser una cuestión de hacer alguna configuración para que esto suceda (agitando la mano vigorosamente ...).
He tenido experiencia al usar esto (BEA WebLogic 7 con BEA WebLogic Integration). Funcionó como se anuncia: "el mundo exterior" no vio el impacto de las cosas de JMS que probé a menos que la transacción se haya realizado correctamente.
Lo que ha descrito es una transacción XA. Esto permite que una transacción abarque múltiples capas, es decir, proveedor JMS, DB o cualquier otro EIS. La mayoría de los contenedores pueden configurarse para usar transacciones que no sean XA y ninguna transacción XA, así que verifique la configuración de su contenedor.
Por ejemplo, si está utilizando JMS con transacciones XA, es posible lo siguiente.
Start Transaction
|
DB Insert
|
Send JMS Msg
|
More DB Inserts
|
Commit Transaction <- Only at this point will the database records be inserted and the JMS message sent.
XA tranactions sólo están disponibles en contenedores llenos de Java EE por lo transacciones XA no están disponibles en Tomcat.
¡Buena suerte!
Karl
- 1. transacción Arjuna JTA rollback inesperadamente
- 2. NUnit Rollback After Test
- 3. Symfony2 Doctrine MongoDB rollback
- 4. Git rollback 1 pull
- 5. Android sqlite rollback
- 6. ¿Se requiere ROLLBACK TRANSACTION?
- 7. SVN Versión Rollback Pregunta
- 8. Rollback un Git fusionar
- 9. Largas sesiones de JMS. Mantener las conexiones JMS/sesiones JMS siempre abiertas ¿una mala práctica?
- 10. Rollback al último git commit
- 11. Cómo deshacer un Git rollback
- 12. Android SQLite Transaction rollback facility?
- 13. Rollback no funciona en MySQL
- 14. Google App Engine: appcfg.py rollback
- 15. Anulado/Ejecución de TransactionScope Rollback
- 16. Rails 3: rollback for after_create
- 17. git equivalente para hg rollback
- 18. rake db: rollback no funciona?
- 19. Cómo rollback de transacciones sin
- 20. savepoint commit rollback en mysql
- 21. Excepción JMS y ActiveMQ
- 22. Java JMS de mensajería
- 23. Cliente JMS genérico
- 24. JBoss JMS Remote Queue?
- 25. mensajes JMS por Node.js
- 26. Corredor liviano JMS
- 27. Procesamiento JMS efectivo
- 28. Implementación de mensajería JMS
- 29. JMS equivalente en .Net
- 30. Tamaño de mensaje JMS
También tener en cuenta el gasto de recursos: http://stackoverflow.com/questions/12305900/performance-overhead-of-xa-data-sources-best-practices – Vadzim