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を発生させないか？再度確認してみてください。