These are chat archives for scalikejdbc/ja

6th
Apr 2015
Shuya Tsukamoto
@tsukaby
Apr 06 2015 00:05
:thumbsup:
Shuya Tsukamoto
@tsukaby
Apr 06 2015 07:03

すみません、mapper generator関係ないのですが、asyncで少し教えていただけないでしょうか?現状公式のサンプルを参考に書いていて、localTxで正しくrollbackできることまで確認しています。
https://github.com/scalikejdbc/scalikejdbc-async

この#createなどのFutureを取ってくる部分をAkkaActorに置き換えると、正しくトランザクション制御できなくなってしまいます。(rollbackされない)
AkkaActorをまたいでlocalTxを継続させることって可能なのでしょうか?ECがそうなのかと思い、これもActorのaskで渡すようにしたんですが、それでもうまくいかず・・・

よろしければActorまたいでlocalTxできるのか教えていただきたいです!
kenji yoshida
@xuwei-k
Apr 06 2015 07:16
もう少し具体的なコード見てみないと色々わからないけど、簡単にはできなそうというか、手軽にやるには「Actorまたいでトランザクション」って筋が悪そうな気がする・・・
そもそもなんでActorまたいでトランザクションという需要が?
Shuya Tsukamoto
@tsukaby
Apr 06 2015 07:21
やはり厳しい感じですか。プロジェクトの方針としてspray使っていることもあり、各レイヤをActorで作ろう!IOレイヤもActorで作ろう!高速化しよう!って感じです。詳しいことはまだ自分も把握していないのですが。
コードは今GitHubにあげてます
kenji yoshida
@xuwei-k
Apr 06 2015 07:23
"各レイヤをActorで作ろう!IOレイヤもActorで作ろう!高速化しよう!" っていうの、気持ちはわからなくもないけど、あまり適してない箇所にまでやり過ぎるとデメリットのほうが多くて酷いことになりそう
簡単に高速化するとも限らないし
Actorとscalikejdbc-asyncの内部のアーキテクチャある程度把握して、ExecutionContextを適切に作って受け渡したり、少しscaliekjdbc-asyncの低レベルなAPIまで呼び出して頑張れば、いい感じに作れそうな可能性もありそうだけど
まず scalikejdbc-async が Actor 経由で使われることを想定してないだろうし、ちゃんとやるなら scalikejdbc-async をある程度ラップ or Actorから使いやすいように数割〜ほぼ作り直し、とかまでしたほうがいいとか?
kenji yoshida
@xuwei-k
Apr 06 2015 07:29
(以上、かなり想像のみで話してるので、全然間違ってて、実はもっと単純な方法ある可能性もありそうだけど)
Shuya Tsukamoto
@tsukaby
Apr 06 2015 07:38
なるほど。即レスありがとうございます。コードはこんな感じで実験しておりました。ExecutionContextを渡すとか渡さないとか色々と。
https://github.com/tsukaby/scalikejdbc-async-sample/blob/master/src/main/scala/MainWithAsync.scala
Actorとasyncはもう一度考えてみます
kenji yoshida
@xuwei-k
Apr 06 2015 08:22
型合ってないのでは
Actorのreceive内でキャストエラー発生してそう
Shuya Tsukamoto
@tsukaby
Apr 06 2015 08:23
なんと・・・
(そもそもECを渡せば上手くいくのかもわかっていない)
kenji yoshida
@xuwei-k
Apr 06 2015 08:26
こういうミス発生しがちなので、使い捨てのプログラムでも、ActorのメッセージにはStringとかTupleとか使わずに、必ず専用のメッセージのclass作るようにしたほうがいいですよ
Shuya Tsukamoto
@tsukaby
Apr 06 2015 08:26
ありがとうございます。ちょっとその辺り変えてきます!
kenji yoshida
@xuwei-k
Apr 06 2015 08:26
動かしてないけど、少なくとも型合わせたやつ xuwei-k/scalikejdbc-async-sample@7a1833b
Shuya Tsukamoto
@tsukaby
Apr 06 2015 08:27
あざます :smile:
kenji yoshida
@xuwei-k
Apr 06 2015 08:28
(専用のメッセージの型作れ、というのはakkaのドキュメントか本にも書いてあった、ある程度基本的なところ)
あと、(単にサンプルだから?かもしれないけど) Actorのaskもあまり頻繁に使うべきものじゃない
専用の受け取るActor用意しておくか、そもそもask多用しないといけないならActorに適していない?か設計が変?な可能性あるので
Manabu Nakamura
@gakuzzzz
Apr 06 2015 08:34
同じ ExecutionContext つかう必要は無さそう
Shuya Tsukamoto
@tsukaby
Apr 06 2015 08:34
正常に動きました・・・!ECちゃんと渡せばセッションは続くんですね。ありがとうございます!
!?
Manabu Nakamura
@gakuzzzz
Apr 06 2015 08:35
Sessionさえ同じであれば動きそうな気配
Shuya Tsukamoto
@tsukaby
Apr 06 2015 08:35
Actorの件勉強になります。ask多用は避けますね。
まじですか・・・ちょっとEC渡さないverもやってみます。
Manabu Nakamura
@gakuzzzz
Apr 06 2015 08:38
あ、 sharedSession つかってるのか。そうすると同一Threadじゃないとダメかな。ちゃんとソース追った方が良さそうです。すみません適当いいました
sharedSession つかってたらそもそもトランザクションにならないような
Shuya Tsukamoto
@tsukaby
Apr 06 2015 08:41
なるほど。
もともとSharedSessionでECなし版を動かしていてlocalTx効いていない!で始まった調査なので、Actor + asyncの構成で良いsession管理方法を探っていた状況です
Manabu Nakamura
@gakuzzzz
Apr 06 2015 08:43
今 EC を渡している代わりに localTx が生成した Session を渡す様にして
Actor側では SharedSession 使わずに渡された Session 使うようにすれば良さそうですね
Shuya Tsukamoto
@tsukaby
Apr 06 2015 08:53
ありがとうございます。反映してこうなりました。
tsukaby/scalikejdbc-async-sample@6849a9b
吉田さんが書いてくださった時点でsharedSession変数は存在するけど、使っていない状態でした。結論としてはActor関係なしに、localTxのとこのimplicit tx(session)使いましょうってことですね
個人的な考えですが、ユーザのリクエスト => applicationレイヤ => domainレイヤ => infraレイヤ みたいな流れで処理が走る時、多分トランザクション境界はapplicationレイヤに置きたいでしょうし、それだと結局Actorでも関数呼び出しでもimplicit sessionを引き回す必要ありで、どっちも同じような感じなんですね。
Skinnyは何かの魔術でどこかしらからsessionが湧いてきて?おお・・・と思った記憶がありますが。
Kazuhiro Sera
@seratch
Apr 06 2015 09:02
ん、thread-local な session 使ってるケース?それ以外は別に普通ですよ。
kenji yoshida
@xuwei-k
Apr 06 2015 09:03
パフォーマンスというかスレッド使いきるためならたぶんFutureで十分で、ある程度複雑な状態を個々のActor内に持つとかの、Actorに適してる場合以外にはActor使うの慎重になったほうが
Shuya Tsukamoto
@tsukaby
Apr 06 2015 09:15
SharedSessionってthread localなのですか? コード追っても見つけられず。
Actorはそうですね、慎重になります。ただ未経験なので使ってみたい病も若干ありまして・・・・Actorダメだったら普通のFuture返すメソッドコールに置き換えようと思います。後でやるときついかもですが
kenji yoshida
@xuwei-k
Apr 06 2015 09:19
少なくともさっきのサンプルだと完全にActorである必要ないパターン
(もちろんサンプルだから単純なのだろうけど?)
Shuya Tsukamoto
@tsukaby
Apr 06 2015 09:29
了解です!
Kazuhiro Sera
@seratch
Apr 06 2015 09:41

SharedSessionってthread localなのですか? コード追っても見つけられず。

いや thread local は skinny の話。skinny orm は thread local session が current thread に存在していればそれを優先するようになってるので、そのことをおっしゃっているのかなと思っただけです。

今見た情報の限りだとこのケースで actor はやめたほうがいいと思います。特に transaction 扱うのなら。
Shuya Tsukamoto
@tsukaby
Apr 06 2015 09:49
あー、なるほど。そういうことですか。うーむ、Actor、ちょっとチームメンバと検討してみます。