XGTx時に別リクエストでコミットしたEntityにアクセスするとConcurrentModificationExceptionが発生する件
XGTxをcommitしたにも関わらず、別リクエストでConcurrentModificationExceptionが起きてしまっている。何故だ・・・。 #gaeja
2013-04-17 21:13:07XGTranでConcurrentModificationExceptionが出る件、分からないからメーリングリストに投げてみるかー #gaeja
2013-04-18 00:43:21むぅ、朝起きてもConcurrentModificationExceptionのままだった・・・ https://t.co/J3qmikZIX3 #gaeja
2013-04-18 08:22:01@sinmetal 不思議だね。logEntityはしっかり書き込まれてたからXGTxは完了しているはずだし。やりたいことは「無かったら別のEGのEntityを書き込みたい」で、 「無かったらそのEntityを書き込む」じゃダメなんだよね?
2013-04-18 09:16:15@vierjp そうなのですよ。3つのEntityが全て揃っていた場合、処理を行うが、そうでない場合はLogEntityを出力するって感じです。ロックが残って、まったく解除されないのがきついorz
2013-04-18 09:19:31@sinmetal ロックが残って消えないのはバグっぽい気がしちゃうね。 人が見るためのログデータならXGTxまで使って厳密にやらなくてもいい、と割りきってしまうのはどうだろうw
2013-04-18 09:27:19@sinmetal @vierjp SDKだとgetOrNullという挙動は元々無くて存在しなくてRuntimeExceptionだったと思うのでSDKとしてはRuntimeException発生したのにそのまま続行して何か処理を進めるというのは考慮してなかったんじゃないかな
2013-04-18 09:28:53@sinmetal ついでにXGTx中では参照しかしなくてもgetのタイミングで競合するそうだからスケーラビリティが気になるかも。http://t.co/j2FXe60BC2 (Noteのところ)
2013-04-18 09:30:43@bluerabbit777jp @vierjp 確かに存在しないKeyをgetすることが、そもそもおかしいということであれば、分からなくもないですね。ただ、一度ロックがかかると、まったく解除される気配が無いというのがorz
2013-04-18 09:34:45@vierjp 確かにスケールする必要がある場合は別の問題が発生しそうですね。ただ、今のパターンはXGTx内でぶつかるのは、1ユーザのみなので、問題は無さそうです。
2013-04-18 09:36:54@sinmetal @vierjp SCN番号が先に進んでしまってるけど、EntityがnullだったからEntityのSCN番号が進めなかったという感じかと
2013-04-18 09:42:42@bluerabbit777jp @vierjp ふむふむ。Entityが無いKeyに対してlockをかけた場合、状態を保存する場所が無いから、tx.commit()もtx.rollbackも効かないということですか・・・。
2013-04-18 09:46:17@sinmetal tx.commitでException発生してます?getOrNullで発生してます?tx.commitですよね?
2013-04-18 09:47:13@bluerabbit777jp @sinmetal ですね。HogeLogはちゃんと書き込まれていたので最初のcommit自体は一応完了しているようですし。
2013-04-18 10:02:36