V12で実装されたODS 55

現場がV11だった関係で、V12には全く触ることなく過ごしてきましたが、現場引退を機に、V12についても少し調べてみることにしました。

V10でODS 53が実装され、その一番のメリットは、最大容量が64GBから256GBに拡張されたことですが、今回は、ACL Entryの総容量、Summary Fieldの容量、Field総容量の増加が行われています。

ACL Entryに関しては、個々に指定されている場合は少ないと思いますので、それ程大きなメリットはないかと思いますが、DJXの組織グループを大量に指定しているような場合には有用かも知れません。

Summary Fieldの容量に関しては、R5の頃だったと思いますが、More Field Support機能が実装され、Summary Fieldの容量が増えたのですが、日本ではWorkflow ApplicationでNotesを使う場合が多く、Summary Fieldが不足するといったこともあるのではないかと思います。

こういう場合の対処方法として、文書の保存時に、LotusScriptでSummary Flagを強制的にOffして保存するといったTechniqueを駆使してWorkflow Applicationを作成したことがある人も居るのではないでしょうか？

今回のSummary Fieldの容量拡張により、こういったTechniqueを使わなくても済むようになれば、Application開発も楽になるのではないかと思います。

V12へのVersion Up時に一気にODS 55にすると、もしもの時に戻すのも大変ですので、Version Up後にFieldを多用したWorkflow Applicationから順次ODSを変更した方が安全です。

V12.0.2 Ealy Access Program Drop 3

年末出荷予定のV12.0.2 Ealy Access Programが実施され、Drop3が提供されているようです。

残念ながら、保守契約を保有したUserでHCLのアカウントを持っていないとD/Lできないようです。

ちょっとだけ、試してみましたが、Serverは正常にInstallできるようですが、DesignerはPackage展開した後に、cabの署名が不正であるかのようなMessageでInstallができないようです。

V12は殆ど使ったこともなかったのですが、V12.0.1でも、WorkspaceがR4.6の頃の3D Workspaceに戻ったりしていて、歴史を感じるVersionですね。

※と思ったら、Setup直後だけで、再起動すると、V12形式になるようです。笑

ただ、Workspace Tabが左側に開閉可能なFrameになっているのが新しい感じです。

mail.boxへ直接書き込みするProgram

皆さんの環境でも、mail.boxに直接書き込みするようなProgramが存在しているのではないかと思います。

良く使われる例として、Mail DBに届いたMailを何も改ざんしない状態で、転送するような場合です。

通常のProgramで転送を行うと、送信者や受信者が変わってしまうことを避けるために、直接mail.boxに文書を保存する処理を行われているのだと思います。

それなら、Domino Directoryの転送Fieldに指定すれば良いのではないか？という声が聞こえてきそうですが、転送設定すると、元のMail DBには配信されずに転送が行われます。

例えば、別の関連会社に出向している人がいて、メールは出向元に配信されるが、出向先でもメールを見たいが、出向から帰任した際にも出向中に受け取ったメールは参照したいというような場合にこのような処理が行われます。

mail.boxへの直接書き込みについては、随分昔(V6の頃だったような記憶がありますが)に全面禁止する方向に動いたことがあり、日本のユーザが反発して中止されたような記憶があります。この反発が多かったと言うことは、日本ではこのようなProgramが多かったのではないかと想像しています。

V11とかV12になって、DBへの書き込みに関するLockの仕組みは昔に比べ、更に厳密さを増しており、Semaphore TimeoutやLong Held Lockの発生頻度が増えていることは皆さんも経験されているのではないでしょうか？

話を元に戻して、メール転送のために、mail.boxへ直接書き込みするProgramを作成して、Mail受信前Agentで動作させた場合を考えてみましょう。

Programを作成して、テストしている時は何のエラーも起こらず、全く気が付くことは無いと思います。

では、一つのサーバで数十人とか数百人がメール転送の設定を行っている状態で、誰かがそのサーバの全ユーザに一斉メールを送信した場合はどうでしょうか？

Routerはメール配信前のAgentを実行させ、同時に数十、数百のAgentが稼働し、mail.boxをOpenし、書き込みを行う状態が発生します。

メールの内容が重かったりすると、書き込みにも当然時間が掛かります。

このような状態になると、一部のメール受信前AgentがI/O待ちになり、Semaphore TimeoutやLong Held Lockで異常終了してしまうことが考えられるのです。

Program上、こういうことを考慮したCodeが書かれていれば問題は発生しないと思いますが、殆どの場合は、特に考慮はなく、単純にmail.boxに書き込みしているのではないでしょうか？

残念ながら、この問題の回避策は、Program修正以外は無いと考えられます。

もし、利用されている環境がTransaction Loggingを有効化している環境であれば、この問題はなかなか顕在化しません。

ProgramからのI/Oが一旦、Transaction Logに書き込まれ、Transaction Logの機能で非同期にmail.boxへの書き込みが行われるだけでなく、Transaction Logの機能で同一DBへの書き込みはシリアライズされて処理されるからです。

ただ、mail.boxへ一度に大量に書き込みが行われるような場合は、Transaction Logに一時的に多量の要求が溜まり、他のTransaction Logを利用しているDBへの影響が無いとは言い切れません。

皆さんも、mail.boxに直接書き込むようなProgramが同時に大量のAccessを発生させないか？再度確認してみてください。