重要な変更点に必要な資格

フィックスパックをローリングリスタート保守の対象外とする変更には、スキームのバージョン変更とクラスタリングコードの変更の2種類があります。

スキーマのバージョン変更

Liferay-Require-SchemaVersionの目的は、モジュールのアップグレードプロセスを実行する必要があるかどうかを判断することです。

• 例 -  Creating Data Upgrade Processes for Modules

基本的に、この値はすべてのモジュールのアップグレードが完了すると、Releaseテーブルのデータベース内部に記録されます。データベース内の値とbnd.bnd内の値が一致しない場合、特定のことが起こらず、サービスビルダーのサービスが他のモジュールに提供されなくなります。
技術レベルでは、Liferayが初期化されると、OSGiコンポーネントとしてサービスビルダーサービスを挿入するコードは、bnd.bndで指定された値が依存関係として必要であると宣言します（したがって、「スキーマバージョンが必要」）。一方、データベース内の値は実際に公開されるものです。これは、2つが一致しない場合、サービスビルダーサービスが利用できなくなるため、ノーリターンポイントが作成されることを意味します。

• 例 - SpringDependencyAnalyzerPlugin
• 例 - ReleasePublisher

   

これは何を意味するかというと、フィックスパックでLiferay-Require-SchemaVersionが変更され、顧客がフィックスパックを適用した場合、一部のコンポーネントの起動に失敗したり（サービスが利用可能であることに依存していたため）、以前のスキーマバージョンを含むデータベースのバックアップを復元しない限り、以前のフィックスパックにロールバックすることはできないということです。

重要： DXP 7.1 と DXP 7.0 では、フィックスパック 40 以降のアップグレード変更のほとんどがローリング リスタート メンテナンスの対象となります。 新しいアップグレードプロセスにはマイクロデータの変更のみが含まれているため、以前のバージョンのコード (フィックスパック 40 以降) は、これらのアップグレード変更と互換性があります。 つまり、フィックスパック40の後にアップグレード処理を含むフィックスパックでローリングリスタートを行うことが可能になります。

クラスタリングコードの変更

ローリングリスタートメンテナンスを行う目的は、クラスタ内の稼働時間を確保することです。 したがって、ローリングリスタートは、パッチインストールの前後でノードがクラスタ内の他のノードと通信できる場合にのみ可能です。時々、フィックスパックにはクラスタリングに影響を与えるコードへの変更が含まれています。 あるノードがクラスタ内の他のノードとは異なるクラスタリングコードベースを持っている場合、他のノードとの間でエラーのない通信が保証されません。

以下のコード変更の種類は、重要な変更点とみなされ、フィックスパックによって修正された場合には、そのフィックスパックはローリングリスタートメンテナンスの対象外となります。

• クラスタリングコードの変更
• いくつかのローカルサービスのインプルクラスの変更
• キャッシングまたはキャッシュレプリケーションコードの変更
• リモートサービスまたはリモートメソッドの変更
• 追加のメソッドキー

DXPのフィックスパックの変更点

フィックスパックがローリング再起動メンテナンスの対象になるかどうかを判断するためには、Liferay ヘルプセンターの「リソース」セクションにある リリースノートツール の「重要な変更」と「モジュールの変更」のセクションを参照してください。 追加リソースとして、以下の表は DXP 7.0 のフィックスパック de-01 から de-40 をカバーしています。

フィックスパック	重要な変更点	リリースノート
de-08	スキーマのバージョンとクラスタリング	リリースノート
de-11	スキーマのバージョン変更	リリースノート
de-14	スキーマのバージョン変更	リリースノート
de-27	スキーマのバージョン変更	リリースノート
de-30	スキーマのバージョン変更	リリースノート
de-33	クラスタリングコードの変更	リリースノート
de-37	スキーマのバージョン変更	リリースノート
de-39	クラスタリングコードの変更	リリースノート
de-40	スキーマのバージョン変更	リリースノート