WebSphere Message Broker バージョン 8.0.0.5 オペレーティング・システム: AIX、HP-Itanium、Linux、Solaris、Windows、z/OS

製品の最新バージョンについては、IBM Integration Bus バージョン 9.0 をご覧ください。

JavaCompute ノードを使用したデータベースとの対話

JavaCompute ノードに組み込まれている Java™ コードからデータベースにアクセスします。

次のようなデータベース対話のオプションの中から選択します。

Type 4 接続用の JDBCProvider または MbSQLStatement を使用する場合、アクセス先のデータベースは、グローバル整合済みトランザクションに参加できます。 他の場合はすべて、データベース・アクセスをグローバル整合することはできません。

Type 4 接続用のブローカー JDBCProvider

JDBC Type 4 接続を確立して、JavaCompute ノードからデータベースと対話することができます。 ブローカーは、Type 4 ドライバーをサポートしますが、このドライバーを提供することはありません。 このドライバーは、データベース・ベンダーから入手する必要があります。サポートされているドライバーについては、サポートされるデータベース を参照してください。

Type 4 接続用のブローカー JDBCProvider を使用すると、次のような利点が得られます。
  • ブローカー構成機能を使用して、簡単に、接続を定義し、オプションのアクションのコーディングを優先しながら、オプションのセキュリティーを実現します。
  • ブローカーが z/OS® 上で稼働する場合を除き、メッセージ・フローからアクセスするその他のリソースへのアクセスと更新を調整するように、ブローカーとデータベースを構成します。
  • ブローカーの JavaAPI getJDBCType4Connection を使用して接続を開始してから、標準の JDBC API を使用して SQL 操作を実行します。 接続、スレッドの親和性、接続プール、およびライフサイクルは、ブローカーによって管理されます。 接続がほぼ 1 分間アイドル状態になった場合や、メッセージ・フローが完了した場合、ブローカーは接続を閉じます。

ブローカーが分散システム上で稼働する場合、他のリソース・アクティビティーとの調整が行われるように、データベースと接続を構成することができます。 分散システム上のグローバル整合は WebSphere® MQ により提供されますが、これには、z/OS システムで定義されているリモート・データベースも含め、ローカルまたはリモートのデータベースとの対話を組み入れることができます。 z/OS で稼働するブローカーからデータベースへの JDBC Type 4 接続を確立した場合、調整は提供されません。 接続と調整のセットアップの詳細は、データベースへの JDBC 接続の使用可能化を参照してください。

ノード用として作成するコードにこの機能を組み入れるには、それに必要な環境を事前に構成する必要があります。 アクセス・セキュリティーがデータベースで必要かどうかと、グローバル整合済みのトランザクションに参加できるようにデータベースを更新するかどうかを決断します。 必須およびオプションのタスクについては、データベースへの JDBC 接続の使用可能化を参照してください。

JDBCProvider の構成を完了したら、MbNode インターフェース上で getJDBCType4Connection 呼び出しを使って、データベースへの JDBC Type 4 接続を確立することができます。 以下のコードは、その使用例を示しています。

public class MyJavaCompute extends MbJavaComputeNode {
    public void evaluate(MbMessageAssembly inAssembly) throws MbException {
      MbOutputTerminal out = getOutputTerminal("out");
      MbMessage inMessage = inAssembly.getMessage();

      // create new message
      MbMessage outMessage = new MbMessage(inMessage);
      MbMessageAssembly outAssembly = new MbMessageAssembly(inAssembly,outMessage);

      try {
        // Obtain a java.sql.Connection using a JDBC Type4 datasource - in this example for a 
        // JDBC broker configurable service called "MyDB2"  

        Connection conn = getJDBCType4Connection("MyDB2",
                     JDBC_TransactionType.MB_TRANSACTION_AUTO);

        // Example of using the Connection to create a java.sql.Statement  
        Statement stmt = conn.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,
                     ResultSet.CONCUR_READ_ONLY);
        ResultSet srs0 = stmt.executeQuery("SELECT NAME, CITY FROM MySchema.MyTable");    

        stmt.executeUpdate("UPDATE MySchema.MyTable SET CITY = ¥"Springfield¥" WHERE Name = ¥"Bart¥"");
        .
        // Perform other database updates   
        . 

      } catch (SQLException sqx ){
        sqx.printStackTrace();
      } finally {
        // Clear the outMessage
        outMessage.clearMessage();
      }     
    }  
  }  

この例の詳細は次のとおりです。

  • MyDB2 は、JDBCProvider 構成可能サービスの名前です。 データベースへの接続のために作成したサービスの名前を使用します。
  • MySchema はデータベース・スキーマの名前です (データベースの名前ではありません)。
  • MB_TRANSACTION_AUTO は、ノードで必要とされるトランザクション調整のレベルを定義します。 この値のみがサポートされています。またこの値は、ノードでの調整は、メッセージ・フロー・レベルで構成された調整から受け継がれていることを示します。

障害の発生を表示し、トランザクションをロールバックするには、JavaCompute ノードから例外を発行します。これによりブローカーがロールバックを処理します。

getJDBCType4Connection 呼び出しは、主に JavaCompute ノードの evaluate() メソッド内で使用されます。その目的は、ブローカーによって管理される JDBC 接続を取得するためです。

WebSphere Message Broker は次のような方法で JDBC 接続を管理します。
  • プールされない接続:
    • WebSphere Message Broker は、JDBC 接続を必要とするメッセージ・フロー・インスタンスごとにオンデマンドで JDBC 接続を作成します。
    • それぞれの JDBC 接続は、作成対象となるメッセージ・フロー・インスタンスに関連付けられます。 この関連付けは、接続が閉じるまで維持されます。
    • JDBC 接続ごとに、60 秒間アイドル状態であったものは閉じられ、メッセージ・フロー・インスタンスとの関連付けもなくなります。
    • メッセージ・フロー・インスタンスに関連付けられた JDBC 接続が閉じられた後、同じメッセージ・フロー・インスタンスで JDBC 接続が必要になった場合、WebSphere Message Broker は新しい JDBC 接続をオンデマンドで作成します。
  • プールされた接続:
    • メッセージ・フロー・インスタンスで JDBC 接続が必要になったとき、WebSphere Message Broker は未使用の接続をプールから割り当てます。
    • プールされたすべての JDBC 接続が使用中である場合、最大プール・サイズに達していなければ、WebSphere Message Broker はプールされた新しい JDBC 接続を作成します。 最大プール・サイズは JDBCProviders 構成可能サービスmaxConnectionPoolSize プロパティーで指定されます。
    • プールされた JDBC 接続とメッセージ・フロー・インスタンスの関連付けは、接続ごとに 1 つの入力メッセージの処理に限定されます。
    • メッセージ・フロー・インスタンスが 1 つの入力メッセージの処理を完了すると、JDBC 接続との関連付けが除去されて、その JDBC 接続はプールに戻されます。
    • プールされた JDBC 接続ごとに、15 分間アイドル状態であったものは閉じられ、プールから除去されます。
    • プールされた JDBC 接続は、DatabaseRetrieve ノードと DatabaseRoute ノードには適用されません。
getJDBCType4Connection 呼び出しを使用する場合は、コードが以下の制約事項に準拠する必要があります。
  • COMMIT や ROLLBACK などの明示的トランザクション呼び出しを行うコードが組み込まれていないこと。 この制約事項には、データベース・ストアード・プロシージャーでの明示的トランザクション呼び出しも含まれます。
  • 接続を閉じたり、接続を JavaCompute ノードでキャッシュに入れたりしないこと。
2 番目の用途として、getJDBCType4Connection 呼び出しは、JavaCompute ノードの onitialize() メソッド内でも使用されます。 onitialize() メソッドは、デプロイ中またはブローカーの起動時に、メッセージ・フローが入力の処理を開始する前に一度呼び出されます。 onitialize() メソッド内で getJDBCType4Connection 呼び出しを使用することで、例えば以下の目的のために、メッセージ・フローが開始する前にデータベースの処理を完了できます。
  • データベースから取得する読み取り専用データのメモリー内キャッシュを作成し、メッセージ・フローでデータベースを照会する必要を減らすため。
  • メッセージ・フローが開始する前に、データベースのデータを事前準備するため。

onitialize() メソッド内で getJDBCType4Connection を使用するときには、この処理で発生する可能性のあるすべての例外が処理されることを確実にしてください。 例外が処理されないと、メッセージ・フローのデプロイメントまたは起動が失敗します。 詳しくは、JavaCompute ノードを参照してください。

MbSQLStatement

MbSQLStatement クラスは、ESQL および ODBC を使用した完全なトランザクション・データベース・アクセスを提供します。 ブローカー・リソース・マネージャーは、MbSQLStatement の使用時にデータベース・アクセスを調整します。 グローバル整合は、分散システムでは WebSphere MQ から提供され、z/OS では RRS から提供されます。 必要な ODBC リソースのセットアップ方法の詳細は、データベースへの ODBC 接続の使用可能化を参照してください。

MbNodecreateSQLStatement() メソッドを使用し、このメソッドに、ODBC データ・ソース、ブローカーの EQSL ステートメント、およびオプションでトランザクション・モードを渡して、MbSQLStatement クラスのインスタンスを作成します。
  • このオブジェクトに対する select() 呼び出しは、照会の結果を戻します。
  • このオブジェクトに対する execute() 呼び出しは、表の更新など、結果が戻されない場合に照会を実行します。
以下の Java コードは、MbSQLStatement を使用してデータベースにアクセスする方法を示しています。
MbMessage newMsg = new MbMessage(assembly.getMessage());
MbMessageAssembly newAssembly = new MbMessageAssembly(assembly, newMsg);

String table = "dbTable";

MbSQLStatement state = createSQLStatement( "dbName", 
	"SET OutputRoot.XMLNS.integer[] = PASSTHRU('SELECT * FROM " + table + "');" );

state.setThrowExceptionOnDatabaseError(false);
state.setTreatWarningsAsErrors(true);
state.select( assembly, newAssembly );

int sqlCode = state.getSQLCode(); 
if(sqlCode != 0)
{
	// Do error handling here 
}

getOutputTerminal("out").propagate(assembly); 

非管理環境での JDBC API

JDBC 呼び出しも含め、JavaCompute ノード用に作成したコード内で、標準の Java API にアクセスすることができます。 したがって、JDBC API を使用して、データベースへの接続、データベースを対象とした書き込みまたは読み取り、およびデータベースからの切断を行うことができます。 z/OS 以外のオペレーティング・システムにおいて、ブローカーは、この環境で Type 2 と Type 4 の両方の JDBC ドライバーを呼び出す JDBC 接続コードをサポートしますが、それを提供するわけではありません。 データベース・ベンダーからこれらのドライバーを入手する必要があります。 z/OS では、Type 2 ドライバーがサポートされません。

このデータベース・アクセス方式を選択した場合、ブローカーはトランザクションの管理をサポートしません。 独自のコードで、データベースの変更のローカル・コミットおよびロールバックを管理する必要があります。 また、接続のライフサイクル、接続スレッドの親和性、および接続プールもコードで管理する必要があります。 さらに、そのような接続が原因で、ブローカーによって確立された接続が妨害を受けないようにするためにこの技法を使用する場合には、データベースへのアクセスもモニターする必要があります。 特に、ESQL からデータベースにアクセスするために、メッセージ・フロー内で使用中の ODBC 接続に、Type 2 ドライバーがブリッジすることに注意してください。

SQLJ

SQLJ は Java の拡張機能であり、これを使用して、静的 SQL ステートメントを Java コード内に組み込むことができます。 SQLJ ファイルを作成するには、WebSphere Message Broker Toolkit を使用します。 SQLJ を使用する場合は、ブローカー・リソース・マネージャーはデータベース・アクセスを調整しません。
  1. 次のようにして、WebSphere Message Broker Toolkit で SQLJ 機能を有効化します。
    1. 「ウィンドウ」 > 「プリファレンス」を選択します。
    2. 「一般」 を展開します。
    3. 「機能」 を選択します。
    4. 「データ」を選択します。
    5. 「OK」をクリックします。
  2. 次のようにして、Java プロジェクト内で SQLJ ファイルを作成します。
    1. ファイルの作成先とする 「Java プロジェクト」 を右クリックします。
    2. 「新規作成」 > 「その他」 を選択します。
    3. 「データ」 を展開します。
    4. 「SQLJ アプリケーション」 を展開します。
    5. 「SQLJ ファイル」をクリックします。
    6. 「次へ」をクリックします。
    7. 「新規の SQLJ ファイル」 ウィザードからの指示に従って SQLJ ファイルを生成します。
これで、このプロジェクトまたは別の参照されるプロジェクトの JavaCompute ノード・クラスから、この SQLJ ファイルのクラスを参照することができます。
特記事項 | 商標 | ダウンロード | ライブラリー | サポート | フィードバック

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        最終更新:
        
        最終更新: 2015-02-28 17:45:49


タスク・トピックタスク・トピック | バージョン 8.0.0.5 | ac30494_