アプリケーションが ObjectGrid インスタンスへの参照またはリモート・データ・グリッドへのクライアント接続を取得すると、データ・グリッド内のデータにアクセスし、対話することができます。 ObjectGridManager API を使用して、ローカル・インスタンスを作成したり、分散インスタンスへのクライアント接続を確立したりすることができます。 ローカル・インスタンスを作成するには、createObjectGrid メソッドの 1 つを使用します。 リモート・データ・グリッドへのクライアント接続を確立するには、getObjectGrid メソッドを使用します。
アプリケーション内のスレッドには、独自のセッションが必要です。アプリケーションがスレッド上で ObjectGrid を使用するようにしたい場合は、getSession メソッドの 1 つを呼び出してセッションを取得します。 アプリケーションがそのセッションを終了した後、Session.close() メソッドを呼び出します。 このメソッドはセッションを閉じて、そのセッションをプールに返し、そのセッションのリソースを解放します。 セッションを閉じるのはオプションですが、そうすると、getSession() メソッドに対する後続の呼び出しのパフォーマンスが向上します。 アプリケーションが、Spring のような依存性注入フレームワークを使用する場合、 必要なときにセッションをアプリケーション Bean に注入する ことができます。
セッションを取得した後、アプリケーションは ObjectGrid 内のマップに保管されたデータ にアクセスできます。ObjectGrid がエンティティーを使用する 場合、Session.getEntityManager メソッドで取得できる EntityManager API を使用できます。 EntityManager インターフェースは、Java 仕様に 近いため、マップ・ベースの API よりもシンプルです。しかし、 EntityManager API はオブジェクト内の変更を追跡するため、 パフォーマンスのオーバーヘッドが生じます。マップ・ベースの API は Session.getMap メソッドを使用して取得されます。
WebSphere eXtreme Scale はトランザクションを使用します。 アプリケーションがセッションとの対話を行う場合、そのセッションはトランザクションのコンテキストの中にある必要があります。トランザクションはセッション・オブジェクトの Session.begin、Session.commit、および Session.rollback メソッドを使用して、開始されたり、コミットまたはロールバックされます。アプリケーションは、 自動コミット・モードで作業を行うこともできます。 このモードの場合、アプリケーションがマップとの対話を行うたび、セッションが自動的に開始し、 トランザクションをコミットします。ただし、自動コミット・モードは低速です。
どの程度のトランザクション・サポートが必要であるかをカスタマイズすることができます。 アプリケーションでロールバック・サポートおよびロックをオフにすることもできますが、アプリケーション側の負担もあります。アプリケーションはこれらのフィーチャーの欠如に対処する必要があります。
例えば、アプリケーションで BackingMap ロック・ストラテジーを NONE に構成することで、ロックをオフにすることができます。このストラテジーは高速ですが、並行トランザクションが互いに保護されずに、同じデータを変更できるようになります。NONE を使用する場合は、そのアプリケーションが、すべてのロックおよびデータの整合性に対する責任を持つことになります。
アプリケーションは、トランザクションによってアクセスされたときのオブジェクトのコピー方法を変更することもできます。アプリケーションは、ObjectMap.setCopyMode メソッドを使用して、オブジェクトがどのようにコピーされるのかを指定できます。 このメソッドを使用して、CopyMode をオフにすることができます。通常、CopyMode を オフにする操作は、1 つのトランザクション内で同じオブジェクトに対して複数の異なる値が戻されることもある場合に、 読み取り専用トランザクションに対して使用されます。1 つのトランザクション内で同じ オブジェクトに対して複数の異なる値が戻されることがあり得ます。
例えば、 トランザクションが T1 でオブジェクトに対して ObjectMap.get メソッドを 呼び出した場合、その時点での値を取得します。 その後の T2 で、そのトランザクションの中で get メソッドが再度呼び出された場合、値は別のスレッドによって変更されている可能性があります。値は別のスレッドによって変更されたため、アプリケーションは異なる値を取得することになります。 NONE CopyMode 値を使用して取得されたオブジェクトがアプリケーションによって変更されると、そのオブジェクトのコミット済みのコピーが直接変更されます。 このモードでは、トランザクションのロールバックは意味がありません。ObjectGrids での唯一のコピーが変更されます。NONE CopyMode を使用すると 処理は速くなりますが、その影響に注意する必要があります。NONE CopyMode を 使用するアプリケーションは、トランザクションを決してロールバックしてはなりません。 もしアプリケーションがトランザクションをロールバックした場合、索引に変更を反映する更新 は行われず、かつ、レプリカ生成がオンにされていても変更は複製 されません。デフォルト値を使用するほうが簡単で、誤りの 可能性も低くなります。データ信頼性を 犠牲にしてもパフォーマンスを上げたい場合は、意図しない問題を回避するために、アプリケーションは 実行内容をよく認識する必要があります。
セッションを取得した後、次のコード・フラグメントを使用して、Map API をデータの挿入に役立てることができます。
Session session = ...;
ObjectMap personMap = session.getMap("PERSON");
session.begin();
Person p = new Person();
p.name = "John Doe";
personMap.insert(p.name, p);
session.commit();
以下は、EntityManager API を使用した場合の同じ例です。このコード例は、Person オブジェクトがエンティティーにマップされていると想定しています。
Session session = ...;
EntityManager em = session.getEntityManager();
session.begin();
Person p = new Person();
p.name = "John Doe";
em.persist(p);
session.commit();
このパターンは、スレッドが使用するマップの ObjectMap への参照を 取得し、トランザクションを開始し、データを操作し、トランザクションを コミットするように設計されています。
ObjectMap インターフェースには、put、get、および remove などの一般的なマップ操作が含まれています。しかし、 get、getForUpdate、insert、update、および remove といった、 より具体的な操作名を使用してください。これらのメソッドは、従来のマップ API より意図を正確に伝えます。
また、フレキシブルな 索引付けサポートを使用することもできます。
以下に、Object の更新の 例を示します。
session.begin();
Person p = (Person)personMap.getForUpdate("John Doe");
p.name = "John Doe";
p.age = 30;
personMap.update(p.name, p);
session.commit();
アプリケーションでは、通常は、単純な get ではなく、getForUpdate メソッドを使用してレコードをロックします。 update メソッドは、更新済みの値を実際にマップに提供するために呼び出す必要があります。 update を呼び出さないと、そのマップは変更されません。以下は、EntityManager API を使用した場合の同じコード断片です。
session.begin();
Person p = (Person)em.findForUpdate(Person.class, "John Doe");
p.age = 30;
session.commit();
EntityManager API はマップを使用した方法よりも単純です。このケースでは、eXtreme Scale がエンティティーを検索し、 管理対象オブジェクトをアプリケーションに返します。アプリケーションがオブジェクトを変更し、 トランザクションをコミットすると、eXtreme Scale は、 管理対象オブジェクトに加えられた変更をコミット時に自動的に追跡し、必要な更新を行います。
WebSphere® eXtreme Scale トランザクションは、単一の区画、更新することができます。クライアントからのトランザクションは複数の区画から読み取ることができますが、更新できるのは 1 つの区画のみです。 アプリケーションが 2 つの区画の更新を試行すると、トランザクションは失敗し、ロールバックが行われます。組み込まれている ObjectGrid (グリッド・ロジック) を使用するトランザクションには、ルーティング機能はなく、ローカル区画内のデータしか認識できません。このビジネス・ロジックは、常に 2 番目のセッションを取得することができます。 この 2 番目のセッションは、他の区画にアクセスするための、本当のクライアント・セッションです。 ただし、このトランザクションは独立したトランザクションです。
トランザクションが既にエンティティーを検索済みの場合、そのトランザクションは、そのエンティティーの区画に関連付けられます。エンティティーと関連付けられたトランザクションで実行する照会 は、関連付けられた区画に送付されます。
以前に関連付けられた区画で照会が実行される場合は、照会に使用される区画 ID を設定する必要があります。区画 ID は整数値です。 これで、その照会はその区画に送付されます。
照会は単一の区画内のみを検索します。ただし、それと同時に同じ照会を、DataGrid API を使用してすべての区画または区画のサブセットに対して実行します。どの区画にあるかわからないエントリーを検索するには、DataGrid API を使用します。
REST データ・サービスは、HTTP クライアントを WebSphere eXtreme Scale グリッドにアクセスできるようにし、Microsoft .NET Framework 3.5 SP1 の WCF Data Services と互換性があります。 詳しくは、REST データ・サービスの構成を参照してください。