Unterschiede zwischen javax.jms.ConnectionFactory und javax.jms.XAConnectionFactory
Ich bin in der Welt der JTA, aufgrund der Notwendigkeit, verteilte Transaktionen, und ich bin unsicher über die Unterschiede zwischen javax.jms.ConnectionFactory
und javax.jms.XAConnectionFactory
oder, genauer gesagt, wie kann es sein, dass javax.jms.ConnectionFactory
durchgeführt, was ich erwartet habe nur javax.jms.XAConnectionFactory
für mich tun kann.
Den details: ich bin mit Atomikos essentials als mein transaction manager und meine app läuft auf Apache Tomcat 6.
Bin ich mit einem kleinen POC mit einer dummy-app, wo ich meine JMS-provider (OpenMQ
) registriert als ein JNDI
Ressource.
<Resource name="jms/myConnectionFactory" auth="Container"
type="com.atomikos.jms.AtomikosConnectionFactoryBean"
factory="com.atomikos.tomcat.EnhancedTomcatAtomikosBeanFactory"
uniqueResourceName="jms/myConnectionFactory"
xaConnectionFactoryClassName="com.sun.messaging.XAConnectionFactory"
maxPoolSize="3"/>
Und das seltsame Problem, dass in meinem code mache ich das:
Context ctx = new InitialContext();
ConnectionFactory queueConnectionFactory =
(ConnectionFactory)ctx.lookup("java:comp/env/jms/myQueueFactory");
javax.jms.Connection connection = queueConnectionFactory.createConnection();
Session session = connection.createSession(true, Session.AUTO_ACKNOWLEDGE);
Später in den code, den ich verwenden Sie diese Sitzung in eine UserTransaction
und es funktioniert einwandfrei mit zwei MessageProducer
s mit entweder Commit
oder Rollback
.
Was ich nicht verstehe ist, wie kann es sein, dass ich mit javax.jms.XAConnectionFactory.createConnection()
- Methode und ich bekomme ein Session
die nicht den job? Was javax.jms.XAConnectionFactory
Rolle?
Werde ich auch hinzufügen, dass ich geschaut habe, auf den Quellcode der beiden Klassen (und javax.jms.BasicConnectionFactory
) und ich habe überprüft, dass die XA-Klasse nicht überschrieben createConnection
.
InformationsquelleAutor Ittai | 2010-11-07
Du musst angemeldet sein, um einen Kommentar abzugeben.
Den Kern der Unterschied zwischen ConnectionFactory und XAConnectionFactory ist, dass die XAConnectionFactory erstellt XAConnections die XASessions. XASessions die wirkliche Unterschied, denn (Zitat aus der JMS JavaDocs🙂
Die XASession-Schnittstelle erweitert die Fähigkeiten der Sitzung durch hinzufügen der Zugang zu einem JMS-provider ist die Unterstützung der Java Transaction API (JTA) (optional). Diese Unterstützung erfolgt in form einer javax.die Transaktion.xa.XAResource-Objekt.
In anderen Worten, die XASession ist es, was den XA-Instanzen Ihre Transaktions-Bewusstsein. Allerdings wird diese spezielle Implementierung ist optional, selbst für eine normenkonforme JMS-provider. Aus dem gleichen JavaDoc:
Eine XAResource bietet einige Recht anspruchsvolle Einrichtungen für interleaving Arbeit auf mehrere Transaktionen, die Wiederherstellung einer Liste von Transaktionen in Bearbeitung, und so weiter. Eine JTA-bewusst JMS-provider muss vollständig implementieren dieser Funktionalität. Umgesetzt werden könnte dies durch die Nutzung der Dienstleistungen einer Datenbank, die unterstützt XA, oder eine JMS-provider können wählen, um diese Funktionalität zu implementieren, von Grund auf.
Ein client der Anwendungs-server ist angesichts dessen, was es denkt, ist ein regelmäßiger JMS-Session. Hinter den kulissen der application server steuert die Transaktion das management der zugrunde liegenden XASession.
In anderen Worten, kann der Anbieter verlangen, dass Sie angeben, dass ein XA oder nicht-XA-JMS-Ressource, oder, wie offenbar in Ihrem Fall, kann der Anbieter die Durchführung aller die JTA-Sanitär-transparent mit, was scheint, ein regelmäßig JMS-Session.
Sorry Ittai, die nicht vertraut mit OpenMQ. Aber es scheint, wie Sie Ihre Tests zeigt ist alles ok. Ich wäre ein bisschen vorsichtiger, wenn Sie Taten, eine zwei-Phasen-commit-Transaktion mit einer Datenbank oder einem anderen JMS-Instanz, aber wie es ist, es ist nicht zu Komplex.
InformationsquelleAutor Nicholas
Eigentlich keines der Beispiel-code, den Sie zur Verfügung gestellt würden, übung XA-Funktionalität. Wenn alles, was erforderlich ist, dass Ihre Nachrichten werden unter syncpoint, dann können Sie mit 1-phase commit (1PC). Allerdings, wenn Sie wollen, zum Beispiel, dass die JMS-Nachrichten und DB-updates erfolgen in einer einzigen koordinierten Einheit der Arbeit, dann verwenden Sie 2-phase-commit (2PC) ist XA. Die Koordination über zwei Nachrichten-Produzenten auf den gleichen transport-provider nicht erforderlich XA-2PC.
Wenn Sie wurden mit 2PC, dann zusätzlich zur COMMIT-und ROLLBACK-Sie benennen würde, BEGINNEN irgendwo in den code. Der Mangel dieses verb in deinem Beispiel ist, warum ich sagte, es sieht aus wie Sie nicht tun, 2PC. Die BEGINNEN Anruf würde die Kommunikation mit dem Transaktions-manager zum herstellen einer Transaktion Kontext über die beteiligten Ressourcen-Managern. Dann BEGEHEN würde veranlassen, dass die Nachrichten und die DB-updates zu beenden, die in einer Einheit von Arbeit. Das interessante hier ist, dass, wenn Sie nur einer beteiligten Ressource-manager, einige Transporte wird automatisch optimieren Sie zurück auf 1PC. In diesem Fall sieht es aus, als ob Sie tun 2PC-aber sind wirklich immer 1PC. Da gibt es nur eine Ressource-manager, gibt es keinen Verlust der Zuverlässigkeit in dieser Optimierung.
Auf der anderen Seite,, wenn Sie tun, 1PC, die Sie nicht sehen, einen Unterschied zwischen den beiden Typen von Verbindungs-factory. Es würde zeigen genau das Verhalten, das Sie beschreiben.
Der Letzte Fall zu betrachten ist, dass Sie ConnectionFactory und versuchen Sie zu rufen BEGINNEN. Da die non-XA connection factory kann nicht teilnehmen, in einer koordinierten XA-Transaktion, so wird dieser Aufruf fehlschlagen sollte.
UserTransaction
das war eine andere Art zu sagen, BEGINNEN die JTA-Transaktion. Ich habe die Notwendigkeit für 2PC wie ich JMS, DB-und Transaktions-Cache sorgen.Ah, OK. Klingt wie das 2PC-optimierte runter zu 1PC da der beschriebene test verwendet zwei message-Produzenten eher als zwei verschiedene Ressourcen-Manager.
InformationsquelleAutor T.Rob