Kris来日

jBPM

今週 jBPM のリード開発者の Kris Verlaenen が日本に来てます。話して結構いろいろもやもやしたところをクリアにできたのでまとめときます。

楽観ロック

jBPM3と同じくjBPM5は楽観ロックベースで実装されています。同じプロセスインスタンスに並行アクセスするとワシワシStaleObjectStateExceptionがでます。一部のお客様には不評で、「悲観ロックを選択可能にしろ」と言われたりします。実際どうやるか、といえばデフォルトではアノテーションで楽観ロックになっているので、orm.xmlで悲観ロックになるように上書きすればできるはず、だけどサンプルはない（よってテストもされていない）。jBPM3にはlockProcessInstance()があったんだけどー。Krisのスタンスは「ほとんどの場合楽観ロックのほうがいいはずだ（だから今まで実装しなかったのだ）。StaleObjectStateExceptionがでたらリトライするんだ」です。でもまあ、実際に要望があるので、何かしら進展すると思いますよー。

ksessionパターン

アプリケーション上でksessionをどう管理するかは非常に重要な問題です。jBPM3では何も考えずにローカルスコープでcreateJbpmContext()するだけだったのですが、jBPM5は自由度が高くて困ります。Krisは「どれが一番というものは無い。ユースケースに応じて変わるんだ」とのことですが、まあ以下のパターンに分類できます。

  • active session
    • アプリケーション内でksessionをずっと生かしておき(disposeしない)、複数のリクエストを並行して処理します。どのプロセスインスタンスの処理も任せます。jBPM Consoleはこのパターンで、ksessionはsingletonです。ksessionは内部でsynchronizeするので、singletonではスケールしません。ですのでアプリケーション内で複数のksessionを持ち、並行リクエスト処理を分散することも考えられます。どちらのパターンも含めて active session パターンとします。デメリットは複数のユーザ・プロセスインスタンスでksessionを共有するのでksessionにステートを持てないことです。つまり、ステートフルにルールを処理できない（1番目のノードでfactをinsert、5番目のノードでfactをinsert、8番目のルールタスクでfire、とか）ということです。
  • session per process instance
    • ksessionのidとprocess instanceのidを紐付けてテーブル管理し、同じprocess instanceにのみ、同じksessionを使います。リクエスト毎にksessionをloadし、処理が終わればdisposeします。メリットは active session と違って、process instanceに合わせてksessionのステートを持てること。こちらのほうが直感的ですね。毎回load/disposeするので比較的robustな実装になること。デメリットはTimerを使うときksessionが生きてないのでTimerが発動しないこと（ぐはぁ）。この問題についてはなにかしらイケてる仕組みをただいま開発者が実装中です。無い間は、Quartzか何かがksessionをloadするような仕組みを自分で実装する必要があります。あと毎回load/disposeするのでパフォーマンス上のオーバーヘッドはactive sessionより大きくなります（並行性は高い）。

ProcessInstanceInfo

ProcessInstanceInfoはProcessInstanceをシリアライズしてbyte arrayで格納します。よってプロセス変数をキーにしてProcessInstanceInfoをクエリできません。「これdisられたんすよー」ってKrisに言ったらちょっとむっとした感じで「ProcessInstanceInfoはランタイム情報を格納するためだけにあるんだ。クエリかけたければHistoryLogを使うんだ」と言われました。HistoryLogで解決できないユースケースがあったら僕に教えてください！

REST API

REST APIに興味を持つお客様は結構おられます。でもねー、どう転んでも「built-inモジュール」なわけです。直接jBPM APIを使う方がはるかに柔軟性があります。サポートで「REST APIにこんな機能が欲しい」とフィードバックをいただけば、喜んで feature request を上げますが、すぐに実装、提供できるとは限らないのです。なので、要件を充分吟味して、現状のREST APIでいける、という確信が無い限り、開発を「REST API縛り」にすることはお勧めしません。Kris曰く「RESTで任意のコマンドを投げられるような改良を進めている」「もし現時点でREST APIが不満足であれば、jBPM APIを使い、自前のRESTラッパーを作ればよい。それほど難しくは無い」とのことです。