このドキュメントには、以下のセクションが含まれています。

• Caché の最新ニュース、アラート、アドバイザリ
• オンライン・ドキュメント
• 変更レポートの説明
• 今回のリリースで重要な変更点のリスト

インターシステムズは、当社のソフトウェアをお使いのユーザに対し、早急に必要となる重要な情報を随時発表しています。この中には、警告、不可避の問題点、重要な更新、修正、Caché のリリースなどがあります。

最新のリストは、インターシステムズの Web サイトから取得できます。

ユーザはこのリストを定期的にチェックし、お使いのアプリケーションの処理に関連する問題がある場合、その最新情報を確認してください。

インターシステムズでは、ユーザの利便性を考慮し、当社 Web サイト で最新バージョンの Caché ドキュメントにオンライン・アクセスできます。

当社ホームページで [Caché] タブをクリックし、[製品情報] メニューの [技術資料とカタログ] を選択してください。あるいはこのリンクをたどってください。

今回の変更による影響をお使いのアプリケーションで認識するため、各変更の解説では、修正点を詳細に説明しています。

すべての変更に対し、問題発生の可能性、変更による影響、実運用しているシステムで製品が問題なく動作しているかなど、関連情報を示した表があります。表では 1 つまたは 2 つのキーワードと値のみ使用し、情報を簡単に認識できるようにしています。キーワードの意味は、以下の通りです。

• 可能性 - 該当するプラットフォームのユーザにこの問題が生じる可能性

• 危険性 - この変更がアプリケーション環境に新たな問題を誘発する可能性

• パッチ - この変更が以前にパッチとして配布され、実運用しているシステムで問題なく動作しているかどうかの有無

• 拡張性 - この変更が新機能や拡張機能を提供するかの有無

CSP ゲートウェイでは、しばらくの間要求を処理しなかった %cspServer プロセッサに対してタイムアウト値が設定されています。この値がサーバー上で失われ、これらの %cspServer プロセッサがタイムアウトするのを阻んでいました。これは、ライセンスを消費したり、重要なリソースを使用したりすることはないため、それほど深刻な問題ではありません。ただし、現在はこのロジックはこれらのジョブをタイムアウトするように修正されています。

あるセッションでセッション管理のためだけに Cookie が使用され、Cookie を提供しない既存のセッションに対する要求が送信され、その要求がそのセッションを指定するのに CSPCHD 引数を使用している場合、エラーが報告されます。このエラー $$$CSPNoCookie は、通常通りエラー・ページにトラップされます。

これは、例えば CSPCHD セッション ID を含むリンクをブックマークして、このリンクを Cookie のみを使用している CSP アプリケーションに対して使用した場合、エラーが発生することを意味します。エラー・ページでは、同じページ (CSPCHD を含まない) に対して HTTP リダイレクトを使用することにより、必要に応じて新しいセッションを作成し続行できます。

HTTPS 接続が #call を含む CSP ページで使用されている場合、以下の HTML 行が挿入されます。

<iframe id="cspBrokerFrame" height="0" width="0" frameborder="0"></iframe>

これは、一部のプラットフォーム上で、#call によって Caché サーバからデータを要求するために使用されます。Internet Explorer のバグにより、HTTPS 接続を使用するページを開いた場合、このタグには 'src' 属性がないため、Internet Explorer はそのページに安全でないオブジェクトが含まれていると報告します。実際には、サーバからデータが読み込まれることはないため、このページはまったく安全です。

HTTPS 接続に対するこのバグを回避するために、今回のリリース以降、存在しないページに指定された 'src' 属性を持つ IFRAME タグを出力するようになりました。これにより、ブラウザがこのページを要求し、"ページが見つかりません" エラーを受け取りますが、それは無視されます。

この回避策により、Internet Explorer、Mozilla、Safari、Opera などでこのページは安全なページとして表示され、作業を適切に続行できます。

ECP リカバリは、すべてのリモート DB パスの長さの合計を 4KB に制限していました。ECP サーバは、すべての DB パスの合計が 4KB を超えていると、リカバリを拒否しました。今回の変更により、この長さは 65KB まで増加されています。

サーバでの 2KB のデータベースに関連する ECP 構成の問題が修正されました。この現象では、単一の文字の名前を持つクライアント参照グローバルが、同じ最初の文字を持つグローバルが消去された後に、誤ったデータベース・エラーおよびその他のエラーを受け取っていました。

%RegisteredObject での %ConstructClone の説明では、親子リレーションシップで親側、または一対多リレーションシップで "一" の側のオブジェクトをシャロー・クローン (deep=0) でクローンした場合に、子/多のオブジェクトもクローンされるということが言及されていませんでした。これは、子/多のオブジェクトが、それぞれ 1 つの親/一オブジェクトしかポイントできないためでした。Caché でこの修正が行われなければ、既存のオブジェクトはクローンされたオブジェクトではなく元の親/一オブジェクトをポイントするため、リレーションシップは常に空になっていました。

今回の変更により、'deep=-1' の新しい引数が導入されました。この引数が設定されると上記の 2 つのリレーションシップのケースでもシャロー・クローンが強制実行されます。その結果、アプリケーションではそのオブジェクトのみがクローンされ、子/多オブジェクトは影響を受けません。

有効なシリアル・クラスの軽量 Java バインディングで、"使用可能なシリアル・ストレージ情報がありません" というメッセージと共に例外が発生するケースがありました。これはクラスのオブジェクトが最初に子テーブルからロードされ、次に組み込みオブジェクトからロードされた場合に発生していました。今回のリリースで、この問題は修正されています。

パフォーマンス・テストでは、軽量 Java バインディングで単一オブジェクトを作成すると、Caché バージョン 5.0.5 に比較して作業速度が 15% 遅くなることが報告されていました。今回のリリースでこの問題は修正され、速度も若干向上しています。

%Date および %Time データ型は、Java クライアントでシリアル化された場合に論理表現に変換されるようになりました。これにより、値が不正になるのを防ぐことができます。

%File:FileSet クエリに報告する多数のファイルがある場合、<STORE> エラーが返されることがありました。現在では、Caché ではこの問題を回避するために、ファイルをソートするのにローカル配列ではなくグローバルを使用するようになりました。

この変更により、SQL トリガ・コードおよび SQL 計算フィールド・コード (ここで計算フィールドはトリガされた計算) でのメソッド呼び出しの使用に関連するエラーが修正されました。現在では、生成されるテーブル・ルーチンのコードは、これらの呼び出しをインスタンス・メソッド呼び出しとしてではなく、クラス・メソッド呼び出しとして処理するようになりました。

常時計算フィールド (一時的なプロパティ) がある場合は、この計算フィールドはキャッシュされたクエリ、組み込み SQL などで生成されるクエリ・ルーチンとなる可能性があるため、#classmethod/#classcontext 設定を各自で処理する必要があります。

最適化されたマルチ・インデックス・アルゴリズムのパフォーマンスが、行 ID やそのコンポーネント上に条件がある以下のようなケースで向上しました。

SELECT %ID FROM t WHERE t.x=? or %ID=?

このようなケースでは、追加の一時ファイルの使用が回避され、結果として全体的なスピードの向上および場合によっては最初の行の取得時間の短縮につながりました。

既定のストレージを使用する場合、スーパクラスから継承されたビットマップではないインデックスのマップ定義には、インデックスを読み込む際に、行が実際に現在のテーブルに属することを確認するために各行に適用する必要がある条件が含まれます。

これまでのリリースでは、このコードはすべての場合には使用されていませんでした。今回の変更により、このコードは適用すべき箇所ではどこでも使用可能になりました。

以下のような日付フィールド上に WHERE 条件があるクエリは、

SELECT * FROM Table WHERE Datefield = {d '2000-01-01'}

Microsoft Query クライアントの ODBC では動作しない可能性がありました。今回の変更により、この不具合が修正されました。

今回の変更により、プロセスで一度により多くの異なるクラスをアクティブにすると共に、プロセスでアクティブに使用されていないクラスをより効率的に処理できるようになりました。

今回の変更により、クラスタ・バックアップの際に生じる <NOLINE> および <UNDEFINED> エラーの原因が解決されました。

並行外部バックアップ中に、システム・アクティビティを静止しようとすると失敗し、バックアップも失敗するという障害が発生していましたが、今回の変更によって修正されました。

今回の変更により、ジャーナリングの終了と開始の後で書き込みイメージ・ジャーナル情報を更新する際の問題が修正されました。この問題によって、スタートアップ時にジャーナル・リカバリが起動できない場合がありました。

複数の CPU を持つ Windows または Linux システムで Entree ライセンス・キーが使用されている場合、ガーベッジ・コレクタ・プロセスでアクセス違反が発生し、システムが正常に起動しないことがありました。Entree 製品タイプはこのタイプのシステムをサポートしていませんが、構成が診断モードで開始され、シングル・ユーザがログインして問題を診断することを許可される必要がありました。今回の変更により、現在は正しく開始されるようになりました。

今回の変更により、添え字のないノードのロックでのロックの共有に関連する 2 つの問題が修正されました。

1. 新しい共有ロックを取得するには、そのロックが共有モードで他のジョブに所有されているとしても、そのロックに待機しているトランザクションがないかどうか待機する必要がありました。

   例えば、ジョブ A が ^a#"S" をロックした場合、ジョブ B の ^a のロックの試行はブロックされ、ジョブ C も ^a#"S" のロックの試行を待機する必要がありました。
   

2. ネットワーク (ECP または DCP) 上に 1 つ以上のジョブがある場合、クライアントはサーバ上の同じ添え字のないノードをロックしようとする場合がありました。サーバ上のジョブがその同じロックに対して競合すると、ハングする可能性がありました。

今回の変更で、ECP クライアント上にロックとアンロックを実行するジョブが 1 つしかない場合に生じる問題が修正されました。ECP サーバにアンロック要求が送信される前に、1 秒の遅延が発生する可能性がありました。これにより、その ECP サーバと対話する別の非 ECP クライアント上で、パフォーマンス問題が発生する可能性がありました。

今回の変更により、添え字のないノードでのロックの共有に関連する問題が修正されました。例えば、以下のような問題がありました。

Process A locked ^A#"S"
Process B locked ^A  <- it will wait here.
Process C locks ^A(1)#"S" should also wait, without this fix it will grant this lock.

SML 490 の変更では、Process C が ^A#"S" をロックする場合の問題が修正されました。

DCP クライアント・ジョブがオープン・トランザクションにある場合、DCP 上でノード (例えば L -^a(1)#"I") を '即座' アンロックすると、クライアント・サイトのロック・エントリが削除されるだけでした。ロックは DCP サーバ上に残っていました。今回の変更により、この問題は修正されています。

ジョブが以下のような親子ノードをロックした場合に、ネットワーク・サーバ・サイドでロック構造の不整合が生じる可能性がありましたが、今回の変更により修正されました。

L +^a(1,2)
L +^a(1)

この変更では、SML 490 と SML 494 によって解決された問題に加えて、添え字のない共有ロックの別の問題が修正されました。例えば、以下のようなケースです。

Job A: L +^a(1)#"S"
JOB B: L +^a         <- it will wait here.
JOB  : L +^a#"S"     <- This should be waiting, but without
                           this fix the job C will grant this lock.

クラスタ・シャドウ上の問題には、以下のような症状があります。

1. シャドウ・デジャーナリングが徐々に遅れる (ただし、再起動後は、シャドウはすぐに遅れを取り戻します)
2. SET の値が不正確になる可能性がある (非常に稀なケースです)

今回の変更により、この不具合が修正されました。

ECP クライアントに要求バッファ・スペースが不足しており、プロセスが ECP で要求をキューに入れるのを待機している場合、待機期間中に接続ステータスが DISABLED または NOT-CONNECTED に変更されると、最初の 100 個のジョブのみが <NETWORK> エラーを返し、残りのジョブは永久的に停止します。

今回の変更で、接続ステータスが通常または回復ではない場合にすべてのジョブが再開され、それらがネットワーク・エラーをクリーンアップするか返すことができるようになりました。