Unofficial oninit blog

IDSの今後のバージョンに入るかもしれない新機能について、分析や解説を試みている人がいます。

http://informix-technology.blogspot.com/

内容の要旨を日本語にしてみました。

Last Commited Concurrency(最新コミット済み並列性)

データ行を読み込む時、もしその行がロックされていたら、その行のロック直前のコミット済み時点の値を読み込む。OracleやPostgresがサポートする分離レベルに類似。
(多分) SET ISOLATION LEVEL TO LAST COMMITED... で使用可能になる（かな？）
当然、あるトランザクションで読み込んだ行は、その後すぐに別のトランザクションで変更されている可能性がある。

Label Based Access Control(「ラベル」に基づくアクセス制御)

明示的な条件に基づきアクセスの許可・不許可を行なう。（行レベル、列レベルでデータに「ラベル」を付け、そこにアクセス許可条件を格納しておく。各ユーザーがアクセスする際、そのユーザーが、アクセス条件を満たす「ラベル」を持っていればアクセスできる。各ユーザーがどんなラベルを持っているかは、データベース･サーバー内で管理する。DB2 9 に実装された新機能と同等。

訳注 - 始め
DB2 では、例えば RDBMS 研究チームとしての全アクセス権を asada さんに許可するラベルを定義する時には、次のような GRANT 文を実行する(らしい)。
(1) 最初に、セキュリティ･ラベル･コンポーネントを定義

CREATE SECURITY LABEL COMPONENT labo SET { 'rdbms', 'os', 'graphics' };
(2) 次に、セキュリティ･ポリシーを作成

CREATE SECURITY POLICY labo_policy
COMPONENTS labo
WITH DB2LBACRULES
RESTRICT NOT AUTHORIZED WRITE SECURITY LABEL;

(3) 続いて、セキュリティ・ラベルの定義

CREATE SECURITY LABEL labo_policy.rdbms_members
COMPONENTS labo 'rdbms';
( 以下、各labo 毎に定義 )

(4) 表を作る時、セキュリティラベルを格納する列を忘れず指定する。

CREATE TABLE docs (
------- ,
----- (省略印) ---,
labo_tag DB2SECURITYLABEL
) SECURITY POLICY labo_policy;

(5) 各ユーザーにラベルを基にしたアクセス権の付与を行なう。

GRANT SECURITY LABEL labo_policy.rdbms_mebers TO USER asada FOR ALL ACCESS

( 以上、DB2 9 のチュートリアル http://www-128.ibm.com/developerworks/edu/dm-dw-dm-0605wong-i.html をもとに、SQL 文を 少しだけInformix 風に書き直したものです。 )
訳注 - 終り

Optimistic concurrency(楽観的並列性)

同時間に実行中の複数のトランザクションが同じ行を変更することはない、という前提にたった並列性実現方法。トランザクション内で行を更新する時、その行にロックをかけない。トランザクションのコミット時、そのトランザクションで更新したすべての行について、別のトランザクションで変更を受けていないか確認し、変更されていない事が確認できればコミットする。もし、前提通りの環境であれば、並列性は向上する。もし、実際にはトランザクション間で同じ行の更新が頻繁に発生している環境であれば、性能は一般のロッキング・メカニズムを使用するより劣化し、更にアプリケーション側に多くの問題を引き起こす可能性がある。

さて、このうち、本当に入るのはどれになるのでしょうか？また、想像は正しいのでしょうか？