Tomcat

JOTMを使用したTomcatのJTA呼び出し



Jta Call Tomcat Using Jotm



少し前に、複数のデータベースにアクセスする必要がある例に遭遇しました。プロジェクトはプロジェクトの開発と展開としてTomcatを使用しているため、特定のベンダーのJTA実装は考慮しませんでしたが、TomcatとマルチソースJTAの実装を完了しました。データベース間の直接相互作用。

マルチデータベースアクセスの最も直接的な問題は、サービス内に複数のデータベースdaoオブジェクトがあることです。現在のdaoオブジェクト操作が完了した後、次のdaoアクセスエラーのいずれかが発生した場合、サービスをどのようにロールバックする必要がありますか？通常、ロールバックはサービス全体で一緒にロールバックする必要があるため、このサービスに関連するすべてのsessionFactoryを処理する必要があります。 hibernate + springの場合、springはトランザクション制御とロールバックにhibernateのsessionFactoryを使用し、hibernateはトランザクションのコミットとロールバックに独自のtransactionFactoryによって関連するトランザクションを参照します。したがって、複数のデータベースを使用する場合は、複数のデータベースをサポートするトランザクションが必要です。 JOTMは、データソース管理にXpoolとXADatasourceを使用するオープンソースのマルチデータベーストランザクションアプリケーションを提供します。



1、最初にプロジェクトに次のパッケージを導入する必要があります。

org.ow2.jotm jotm-core 2.2.1 com.experlog xapool 1.5.0 org.ow2.jotm jotm-datasource 2.2.1 org.ow2.cmi cmi-all 2.0-RC7 geronimo-spec geronimo-spec-j2ee-connector 1.5-rc4

2、構成ファイルのルートにcarol.propertiesファイルを追加します（このファイルは名前空間とjndi構成のサポートです）



carol.protocols=jrmp carol.jvm.rmi.local.call=true carol.start.jndi=false carol.start.ns=false carol.jndi.java.naming.factory.url.pkgs=org.apache.naming

3、プロジェクトでデータソース接続を構成します。ここでは、SpringまたはHibernate構成ファイルでデータソースを構成できません（もちろん、xadatabaseとして構成されている場合は、正しく構成されていません）。 Webアプリケーションでは、META-INFフォルダーがwebappの下に新しく作成され、context.xmlファイルが新しく作成されます。 （一部のファイルは、tomcatのservice.xmlで直接作成されると言っていますが、実際には、各プロジェクトでより独立しています。）tomcatは、プロジェクトのロード時にこのファイルを自動的にロードします。

gtip jdbc/gtip javax.sql.DataSource gtip jdbc/gtipext javax.sql.DataSource

ここでは、gtip用とgtipext用の2つのデータソースが作成され、デフォルトのトランザクションUserTransactionが宣言され、トランザクションプロバイダーが宣言されます。これは、トランザクションの実装がjotmによって提供されることを示します。

4.プロジェクト内の2つのデータソースを参照します。つまり、web.xml内のデータソースを参照します。



java:comp/env/jdbc/gtipext

これは、2つのデータソース定義を参照する必要があることを意味します。

5、hibernate.cfg.xmlでデータソースを構成し、このデータソースが参照されていることを示します

|_+_|

これはgtipextのデータソースを参照し、hibernateがこれを使用して対応するデータソースの実装を見つけることを示します。

6、spring.xmlでトランザクションを構成し、関連するjtaTransactionFactoryを参照するようにhibernateに通知します。

|_+_|

これはjotmBeanの定義です。このBeanはSpring3.xバージョンでは使用できなくなったため、Spring2.5.6バージョンから直接ソースコードをコピーできます。これは、最終的にjotm currentオブジェクトを作成するためのファクトリBeanです（または作成されませんが、静的参照Current.getCurrent（）を介して直接作成されます）。ここでは、jotmオブジェクトに到達するための手段が必要です。

トランザクションマネージャー宣言。これは、jtaトランザクションマネージャーが定義されていることを意味します（実際には、transactionManagerインターフェイスはまったく実装されていません）が、最終的なトランザクション管理は特定のtransactionManagerによって実装され、transactionManagerの実装作業は次のようになります。コンテナまたは特定の実装に委任されます。 。
|_+_|
jtaTransactionManagerプロパティ定義を必要とするHibernateのsessionFactory定義宣言は、hibernateがこのプロパティを解析するときに、hibernateのtransactionFactory実装をJTATransactionFactoryとして指定します（デフォルトでは、JDBCTransactionFactoryとして指定されます）。
 
この時点で、対応する構成作業は終了しました。プロジェクトでは、Springと以前のトランザクション制御aopの定義、および関連するtransactionManagerを使用して制御できます。
 
PS：Spring AnnotationSessionFactoryBeanで、jtaTransactionManagerを構成した後、Springはhibernateでプロパティhibernate.transaction.manager_lookup_classを構成し、hibernateを参照して対応するtransactionManagerを見つけます。ただし、実装の3.5.3バージョンでは休止状態になり、lookupClassを使用してtransactionMangerを検索するのではなく、lookupClassを使用してuserTransactionNameを検索し、次にuserTransactionNameを介してinitContextを介してtransactionManagerを取得します。 srping3.xの実装では、lookupClassのgetUserTransactionName（つまり、LocalTransactionManagerLookup）はnullを返します（ただし、そのgetTransactionManagerは対応するtransactionManagerを返します）。このメソッドを使用する代わりに、hibernateはgetTransactionUsernameメソッドを使用します。 2つは適切なドッキングを示していないか、1つはよく考えられていません。