永続オブジェクトを使用した作業

Rollback

%Save() メソッドは、SaveSet 内のすべてのオブジェクトを単独のトランザクションとして自動的に保存します。これらのオブジェクトのいずれかの保存が失敗した場合、トランザクション全体がロール・バックされます。このロールバックの場合、InterSystems IRIS は以下を実行します。

1. 割り当てられた ID を元に戻します。

2. 削除された ID を回復します。

3. 変更されたビットを回復します。

4. 正常にシリアル化されたオブジェクトに対して、%OnRollBack() コールバック・メソッドを呼び出します (実装されている場合)。

   InterSystems IRIS は、正常にシリアル化されていないオブジェクト (つまり、無効なオブジェクト) に対しては、このメソッドを呼び出しません。

オブジェクトとトランザクションの保存

前述したように、%Save() メソッドは、SaveSet 内のすべてのオブジェクトを単独のトランザクションとして自動的に保存します。これらのオブジェクトのいずれかの保存が失敗した場合、トランザクション全体がロール・バックされます。

複数の関連しないオブジェクトを 1 つのトランザクションとして保存する場合は、%Save() の呼び出しを 1 つの明示的なトランザクション内にまとめる必要があります。つまり、TSTART コマンドを使用してトランザクションを開始し、TCOMMIT コマンドを使用してトランザクションを終了する必要があります。

例 ：

 // start a transaction
 TSTART

 // save first object
 Set sc = obj1.%Save()

 // save second object (if first was save)
 If ($$$ISOK(sc)) {
     Set sc = obj2.%Save()
 }

 // if both saves are ok, commit the transaction
 If ($$$ISOK(sc)) {
     TCOMMIT
 }

上記の例では、注意すべきことが 2 つあります。

1. %Save() メソッドは、トランザクション内で呼び出されたかどうかを知っています (システム変数 $TLEVEL が 0 より大きいため)。

2. トランザクション内の %Save() メソッドが失敗した場合、トランザクション全体がロール・バックされます (TROLLBACK コマンドが実行されます)。これは、アプリケーションは明示的なトランザクション内のすべての %Save() をテストし、いずれか 1 つが失敗したら他のオブジェクトでの %Save() の呼び出しをスキップし、最終的な TCOMMIT コマンドの呼び出しもスキップする必要があることを意味しています。

ObjectScript によるオブジェクトの存在のテスト

%ExistsId() クラス・メソッドは、指定された ID を確認します。指定されたオブジェクトがデータベース内に存在する場合は True (1) の値を返し、それ以外の場合は False (0) を返します。これは、%PersistentOpens in a new tab から継承されたすべてのクラスで使用できます。以下に例を示します。

 Write ##class(Sample.Person).%ExistsId(1),!   // should be 1 
 Write ##class(Sample.Person).%ExistsId(-1),!  // should be 0

ここでは、最初の行が 1 を返します。これは、Sample.Person が %PersistentOpens in a new tab を継承していて、SAMPLES データベースは、このクラスにデータを提供するためです。

%Exists() メソッドも使用できます。このメソッドには、ID ではなく OID が必要になります。OID はデータベースに対して一意の永続識別子で、オブジェクトの ID とクラス名の両方が含まれます。詳細は、"保存したオブジェクトの識別子 ： ID および OID" を参照してください。

SQL によるオブジェクトの存在のテスト

保存したオブジェクトの存在を SQL でテストするには、指定した ID と一致する %ID フィールドを持つ行を選択する SELECT 文を使用します (保存したオブジェクトの identity プロパティは、%ID フィールドとして投影されます)。

例えば、以下のように埋め込み SQL を使用します。

 &sql(SELECT %ID FROM Sample.Person WHERE %ID = '1')
 Write SQLCODE,!  // should be 0: success

 &sql(SELECT %ID FROM Sample.Person WHERE %ID = '-1')
 Write SQLCODE,!  // should be 100: not found

ここでは、最初のケースは結果として 0 の SQLCODE を返します (成功を意味します)。これは、Sample.Person が %PersistentOpens in a new tab を継承していて、SAMPLES データベースは、このクラスにデータを提供するためです。

2 つ目のケースは、文の実行は成功したもののデータは返されないことを示す SQLCODE 100 になります。システムは 0 未満の ID を自動的には生成しないため、このように想定されます。

埋め込み SQL の詳細は、"InterSystems SQL の使用法" の “埋め込み SQL” を参照してください。SQLCODE の詳細は、"InterSystems IRIS エラー・リファレンス" の “SQLCODE 値とエラー・メッセージ” を参照してください。

%OpenId() に対する複数の呼び出し

%OpenId() が 1 つの InterSystems IRIS プロセス内で同じ ID と同じオブジェクトに対して複数回呼び出された場合、メモリに作成されるオブジェクト・インスタンスは 1 つのみです。それ以降の %OpenId() の呼び出しはすべて、既にメモリにロードされているオブジェクトへの参照が返されます。

例えば、同じオブジェクトへの複数回の %OpenId() 呼び出しを特徴とする以下のクラスを見てみましょう。

Class User.TestOpenId Extends %RegisteredObject
{

ClassMethod Main()
{
   set A = ##class(Sample.Person).%OpenId(1)
   write "A: ", A.Name

   set A.Name = "David"
   write !, "A after set: ", A.Name

   set B = ##class(Sample.Person).%OpenId(1)
   write !, "B: ", B.Name

   do ..Sub()

   job ..JobSub()
   hang 1
   write !, "D in JobSub: ", ^JobSubD
   kill ^JobSubD

   kill A, B
   set E = ##class(Sample.Person).%OpenId(1)
   write !, "E:", E.Name
}

ClassMethod Sub()
{
   set C = ##class(Sample.Person).%OpenId(1)
   write !, "C in Sub: ", C.Name
}

ClassMethod JobSub()
{
   set D = ##class(Sample.Person).%OpenId(1)
   set ^JobSubD = D.Name
}

}

Main() メソッドを呼び出すと、以下のような結果になります。

1. 最初の %OpenId() 呼び出しは、インスタンス・オブジェクトをメモリにロードします。A 変数はこのオブジェクトを参照しており、この変数によって、ロードされたオブジェクトを変更できます。

      set A = ##class(Sample.Person).%OpenId(1)
      write "A: ", A.Name
   

   

   A: Uhles,Norbert F.

      set A.Name = "David"
      write !, "A after set: ", A.Name
   

   

   A after set: David

2. 2 つ目の %OpenId() 呼び出しは、データベースからオブジェクトを再ロードすることも、変数 A を使用して加えられた変更を上書きすることもありません。その代わり、変数 B が変数 A と同じオブジェクトを参照します。

      set B = ##class(Sample.Person).%OpenId(1)
      write !, "B: ", B.Name
   

   

   B: David

3. 3 つ目の %OpenId() 呼び出しは、Sub() メソッド内にあり、これも既にロードされているオブジェクトを参照します。このメソッドは、Main() メソッドと同じ InterSystems IRIS プロセスに含まれています。変数 C は、変数 A および変数 B と同じオブジェクトを参照します。ただし、変数 A と B はこのメソッドのスコープ内では使用できません。Sub() メソッドの最後に、プロセスは Main() メソッドに戻り、変数 C は破棄され、変数 A および B はスコープ内に戻ります。

      do ..Sub()
   

   

   ClassMethod Sub()
   {
      set C = ##class(Sample.Person).%OpenId(1)
      write !, "C in Sub: ", C.Name
   }

   

   C in Sub: David

4. 4 つ目の %OpenId() 呼び出しは、JobSub() メソッド内にあり、JOB コマンドを使用して別個の InterSystems IRIS プロセスで実行されます。この新しいプロセスは、新しいインスタンス・オブジェクトをメモリにロードし、変数 D でこの新しいオブジェクトを参照します。

      job ..JobSub()
      hang 1
      write !, "D in JobSub: ", ^JobSubD
      kill ^JobSubD
   

   

   ClassMethod JobSub()
   {
      set D = ##class(Sample.Person).%OpenId(1)
      set ^JobSubD = D.Name
   }

   

   D in JobSub: Uhles,Norbert F.

5. 5 つ目の %OpenId() 呼び出しが実行されるのは、ロード済みのオブジェクトを元のプロセスで参照している変数 (A および B) をすべて削除し、それによってそのオブジェクトをメモリから削除した後です。直前の %OpenId() 呼び出しと同様に、この呼び出しも新しいインスタンス・オブジェクトをメモリにロードし、変数 E でこのオブジェクトを参照します。

      kill A, B
      set E = ##class(Sample.Person).%OpenId(1)
      write !, "E:", E.Name

   

   E: Uhles,Norbert F.

複数回ロードされるオブジェクトを強制的に再ロードするには、%Reload() メソッドを使用します。オブジェクトを再ロードすると、そのオブジェクトに対する未保存の変更は元に戻されます。以前に割り当てられていた変数は、再ロードされたバージョンを参照します。以下に例を示します。

 set A = ##class(Sample.Person).%OpenId(1)
 write "A: ", A.Name // A: Uhles,Norbert F.
 
 set A.Name = "David"
 write !, "A after set: ", A.Name // David
 
 set B = ##class(Sample.Person).%OpenId(1)
 write !, "B before reload: ", B.Name // David

 do B.%Reload()
 write !, "B after reload: ", B.Name // Uhles,Norbert F.
 write !, "A after reload: ", A.Name // Uhles,Norbert F.

並行処理

%OpenId() メソッドは、入力としてオプションの concurrency 引数を取ります。この引数は、オブジェクト・インスタンスを開くために使用する並行処理レベル (ロックのタイプ) を指定します。

%OpenId() メソッドがオブジェクトのロックを取得できない場合、メソッドは失敗します。

オブジェクトに対する現在の並行処理レベルの設定を上げ下げするには、そのオブジェクトを %OpenId() で再度開いて別の並行処理レベルを指定します。以下はその例です。

 set person = ##class(Sample.Person).%OpenId(6,0)

並行処理レベル 0 でperson を開き、以下のようにして並行処理レベルを事実上 4 まで引き上げます。

 set person = ##class(Sample.Person).%OpenId(6,4)

並行処理レベル 3 (共有保持ロック) または 4 (共有排他ロック) を指定すると、オブジェクトを開くときにそのオブジェクトが強制的に再ロードされます。可能なオブジェクト並行処理レベルの詳細は、"オブジェクト同時処理のオプション" を参照してください。

%DeleteId() メソッド

%DeleteId() メソッドは、データベース内に保存されているオブジェクトを削除します。これには、オブジェクトに関連付けられているストリーム・データも含まれます。このメソッドは、以下のとおりです。

classmethod %DeleteId(id As %String, concurrency As %Integer = -1) as %Status

以下はその説明です。

• id は、開くオブジェクトの ID です。

  この例では、ID は整数です。次の章では、ID がオブジェクトの固有プロパティに基づくようにクラスを定義する方法について説明しています。

• concurrency は、オブジェクト削除時に使用する並行処理レベル (ロック) です。

例 ：

 Set sc = ##class(MyApp.MyClass).%DeleteId(id)

%DeleteId() は、オブジェクトが削除されたか否かを示す %StatusOpens in a new tab 値を返します。

オブジェクトが削除される前に、%OnDelete() コールバック・メソッドが存在していれば、%DeleteId() はそれを呼び出します。%OnDelete() は %StatusOpens in a new tab 値を返します。%OnDelete() がエラー値を返した場合、オブジェクトは削除されず、現在のトランザクションがロール・バックされ、%DeleteId() はエラー値を返します。

オブジェクトが削除された後に、%OnAfterDelete() コールバック・メソッドが存在していれば、%DeleteId() はそれを呼び出します。この呼び出しは、%DeleteData() がエラーを返さない限り、%DeleteData() が呼び出された直後に行われます。%OnAfterDelete() がエラーを返す場合、現在のトランザクションはロール・バックされ、%DeleteId() はエラー値を返します。

最後に、%DeleteId() は、%OnDeleteFinally() コールバック・メソッドが存在する場合は呼び出します。このコールバック・メソッドは、トランザクションが完了し、削除のステータスが確定した後に呼び出されます。

%DeleteId() メソッドは、メモリ内のオブジェクト・インスタンスには効果がありません。

%Delete() メソッドも使用できます。このメソッドには、ID ではなく OID が必要になります。OID はデータベースに対して一意の永続識別子で、オブジェクトの ID とクラス名の両方が含まれます。詳細は、"保存したオブジェクトの識別子 ： ID および OID" を参照してください。

%DeleteExtent() メソッド

%DeleteExtent() メソッドは、エクステント内のすべてのオブジェクト (およびオブジェクトのサブクラス) を削除します。具体的には、エクステント全体を反復処理して、各インスタンスで %DeleteId() メソッドを起動します。

%KillExtent() メソッド

%KillExtent() メソッドは、オブジェクトのエクステントを保存するグローバルを直接削除します (ストリームに関連付けられたデータは含まれません)。%DeleteId() メソッドは呼び出されず、参照整合性アクションも実行されません。このメソッドは、単に開発段階で開発者を支援することを目的としています (従来のリレーショナル・データベース製品にある TRUNCATE TABLE コマンドに類似したものです)。関連付けられているストリーム・データを含め、エクステント内のすべてのオブジェクトを削除する必要がある場合は、代わりに %DeleteExtent() を使用してください。

並行処理を指定する理由

以下のシナリオでは、オブジェクトの読み取り時または書き込み時に、適切に並行処理を制御することが重要になる理由についての例を示しています。以下の例を考えてみます。

1. プロセス A は、並行処理を指定せずにオブジェクトを開きます。

   SAMPLES>set person = ##class(Sample.Person).%OpenId(5)
    
   SAMPLES>write person
   1@Sample.Person
   

   

2. プロセス B は、同じオブジェクトを並行処理値 4 で開きます。

   SAMPLES>set person = ##class(Sample.Person).%OpenId(5, 4)
    
   SAMPLES>write person
   1@Sample.Person
   

   

3. プロセス A がオブジェクトのプロパティを変更し、%Save() を使用してそれを保存しようして、エラー・ステータスを受け取ります。

   SAMPLES>do person.FavoriteColors.Insert("Green")
   
   SAMPLES>set status = person.%Save()
    
   SAMPLES>do $system.Status.DisplayError(status)
    
   ERROR #5803: Failed to acquire exclusive lock on instance of 'Sample.Person'
   

   

これは、適切な並行処理の制御がない場合の同時処理の例です。例えば、プロセス A がオブジェクトをディスクに保存する可能性がある場合、他のプロセスと競合せずにオブジェクトを保存できるように、並行処理 4 でオブジェクトを開く必要があります。(これらの値については、この章で後述します)。この場合、プロセス B はアクセスを拒否される (並行処理違反で失敗する)、またはプロセス A がオブジェクトを解放するまで待機する必要があります。

並行処理の値

このセクションでは、有効な並行処理の値について説明します。まず、以下の詳細に注意してください。

• アトミック書き込みは、並行処理が 0 より大きいときに保証されます。

• InterSystems IRIS は、オブジェクトの保存や削除などの処理中にロックの取得と解放を実行します。詳細は、並行処理の値 (どのような制約があるのか、ロック・エスカレーションのステータス、およびストレージ構造) によって異なります。

• どのような場合でも、オブジェクトがメモリから削除されると、そのオブジェクトのロックも削除されます。

有効な並行処理の値は、以下のとおりです。このリストも示すように、それぞれの値には名前が付いています。

並行処理とスウィズルされたオブジェクト

プロパティによって参照されるオブジェクトは、スウィズルされるオブジェクトのクラスで定義された既定の並行処理を使用してアクセス時にスウィズルされます。そのクラスの既定値が定義されていない場合、オブジェクトは、プロセスの既定の並行処理モードを使用してスウィズルされます。スウィズルされるオブジェクトは、それをスウィズルするオブジェクトの並行処理値は使用しません。

スウィズルされるオブジェクトが既にメモリ内にある場合は、実際にスウィズルによってオブジェクトが開かれることはありません。それは、既存のメモリ内のオブジェクトを参照するだけであり、その場合、そのオブジェクトの現在の状態が保持され、並行処理は変更されません。

この既定の動作をオーバーライドするには、以下の 2 つの方法があります。

• スウィズルされたオブジェクトに対する同時処理を、新しい同時処理を指定する %Open() メソッドの呼び出しでアップグレードします。以下に例を示します。

   Do person.Spouse.%OpenId(person.Spouse.%Id(),4,.status) 

  

  %OpenId()Opens in a new tab の最初の引数では ID を指定し、2 番目の引数では新しい並行処理を指定し、3 番目の引数 (参照渡し) はメソッドのステータスを受け取ります。

• オブジェクトをスウィズルする前に、プロセスの既定の並行処理モードを設定します。以下に例を示します。

   Set olddefault = $system.OBJ.SetConcurrencyMode(4) 

  

  このメソッドは、その引数として新しい同時処理モードを取り、前の同時処理モードを返します。

  異なる並行処理モードが必要なくなった場合は、以下のように既定の並行処理モードをリセットします。

   Do $system.OBJ.SetConcurrencyMode(olddefault)