Seasoft

発生した経緯から MTA が切っていると思っていましたが、Swift の処理時点で切っている予感もしてきました。 ```php // パターン1 長いと途中で (エンコード後256バイトで?) ぶった切る【悪質】 ->setFrom(['[email protected]' => 'ながーーーーーーーーーーーーーーい店舗名']) /* 配信されたヘッダー From: =?utf-8?Q?=E3=81=AA=E3=81=8C=E3=83=BC=E3=83=BC?= =?utf-8?Q?=E3=83=BC=E3=83=BC=E3=83=BC=E3=83=BC?= =?utf-8?Q?=E3=83=BC=E3=83=BC=E3=83=BC=E3=83=BC?= =?utf-8?Q?=E3=83=BC=E3=83=BC=E3=83=BC=E3=83=BC?= =?utf-8?Q?=E3=81=84=E5=BA=97=E8=88=97=E5=90=8D?= setFrom(['[email protected]' => 'ながーーーーーーーーーーーーーーーーい店舗名']) /* 配信されたヘッダー From: */ ```

LC_Page_Admin_Products_Product は、 ``` parent::lfInitParam($objFormParam); ``` として、参照がある様子。 動作としては良いのだろうが、設計的に違和感がある。

> 本来セッションの書き込みはアトミックであるべきだと思われますので、C案の動作が正しいと思われます。 そんな気はします。ただ、DBコネクション2倍は、結構インパクトあるかなと。繋ぎ直すのもオーバーヘッドありそうですし、かと言って持続的接続なんかも良し悪しありそうですし。 > 歴史的な経緯で、2系はDBセッション採用していますが、スケールアウトしない限りはファイルセッションでも問題ないと思いますので、本不具合の解消にはファイルセッションを利用するのも良さそうです はい。この課題の対応とは別として、実運用ではそれも有力かなと思います。 試したことありませんが、ファイルの方がパフォーマンスも良いですよね。 ただ、他の PHP アプリと session_save_path が一緒だと怖い気がするので、data/ 以下に保存するとかでしょうか。 http://svn.ec-cube.net/open_trac/ticket/621 に期待してます😁

> 本来セッションの書き込みはアトミックであるべきだと思われますので、C案の動作が正しいと思われます。 C案に関しましては、http://svn.ec-cube.net/open_trac/ticket/571 に有効そうなので、#498 で対応を検討したいと思います。その中で、ファイルセッションの選択肢も用意することで、DBコネクション2倍問題は許容できるのではないかと目論んでいます。 ただ、C案では、『「2」は保存されなくて良い。』を満たせない気がしてきたので、A案・B案 は引き続き対応を考えたいと思います。

メモです。 A案の以下について。 > dtb_session に書き込む段階で、トランザクション内の場合、ロールバックする。 SC_Helper_Session::sfSessWrite() 内でロールバックし、連鎖して「ロールバックのタイミングでセッション変数を復元する。」が実行されても、$sess_data はセットされた後なので、バックアップしていた内容に復元されない。 現実装であれば、以下のコードで回避できる。 ``` if ($objQuery->rollback()) { $sess_data = session_encode(); } ``` しかし、#498 により、ファイルセッションに対応すると、SC_Helper_Session::sfSessWrite() を通らなくなると考えられるので、別の対応を考える必要がある。(けど、そんなのトラップできる???) B案に関しても、ファイルセッションだと、「SC_Helper_Session_Ex::sfSessWrite() を自力で呼ぶ」は通用しなくなるので、別の対応を考える必要がありそう。 A案・B案ともボツなら、各処理側で処理順序を徹底する方向だろうか。 1. トランザクション開始。 2. DB処理する。 3. コミット。...

@nobuhiko >ファイルセッションに対応すると、SC_Helper_Session::sfSessWrite() を通らなくなる がよくわからないんですけど、session_set_save_handler を使えば通りますよ ファイルセッション (PHP 標準) は、session_set_save_handler() と併用可能でしたでしょうか?

@nanasess > スケールアウトが必要な大量のトラフィックを捌く必要がある場合は、DBセッションはかえってボトルネックになりそうですので、 radis のような外部ストレージを使用するようにした方が良さそうな。 Redis でしょうか。その辺りの対応は、個別サイトでのカスタマイズの範疇ですよね。それを阻害するような実装にならなければ良いのかなと思っています。 その前提で、さらに「dtb_session いらねー」という結論に合意形成できれば、dtb_session を無くす方が簡単ですね。今のところ、個人的な理想としては、そうしたいですが。

@nobuhiko 貴重な情報ありがとうございます。 「dtb_session は常に不要なので」 なるほど(笑) そんな気はしていましたが、参考になります。 ちなみに「session_set_save_handler を使わないとうまく動かない」というのは、どういった辺りでしょうか? 個別のサイトの要件に依るカスタマイズといった部分は置いておいて、ファイルセッションを使うに当たり、多くのサイトで共通して必要だった対応などありましたら教えて下さい。(それとも、EC-CUBE が標準で session_set_save_handler() を使っているが故に、使っておかないと不都合があったなどでしょうか。)

@nobuhiko > Fatal error(E_ERROR): Uncaught Error: Call to a member function doAction() on bool ってよくわからないエラーになります。 なるほど。なるほど。確かに試した際に、謎な動作だったので、サクッと削ってました。 ```diff diff --git a/data/class/helper/SC_Helper_Plugin.php b/data/class/helper/SC_Helper_Plugin.php index bbab889..04c6395 100644 --- a/data/class/helper/SC_Helper_Plugin.php +++ b/data/class/helper/SC_Helper_Plugin.php @@ -91,13...

プラグインは、SC_Query や SC_Query_Ex をオーバーライドできるんでしたっけ? もしできないなら、ネックになっている部分の処理を、簡素化できそうな気がして。 そのうち調べようかと思いますが、ご存知でしたら教えて下さい。