モジュールを導入し、GMOのサンドボックスで、
動作確認させてみましたが「.../db/...」は確認出来ませんでした。

var_dump()での動作表示でも、「..._EX」が $class に引き渡されることも確認出来ず。。。

やはり、本件は、プラグイン機能で導入した autoloader機能 を
memcache が、コーディグミスの「_EX」で、上書いてしまっているのではないでしょうか？

小生の知識では、ここまでで、手詰まり。。。

「_EX」を「_Ex」に修正し、追加した require を外しても、再現する様であれば、、、
他の、識者の見解を待ちたいと思います。。。

知識不足で申し訳ない。。。m(_ _)m

「GMO-PG決済モジュール(PGマルチペイメントサービス)(2.12系)」です。

わざわざ調査して頂きありがとうございます。

http://log.noiretaya.com/191

こちらにあるように、やはりロード済みクラスをキャッシングしているようですね。

この処理中で、文字列自体に差異がなければPHPの特性上、大文字小文字の比較なくロード済みクラスを使用していたのかもしれません。
（SC_HElPer_DB_EXとしても、一度SC_Helper_DB_Exで正常なロードをしていれば使いまわせる）

実際、SC_HElPer_DBB_EXなどとすれば、直接この名前がクラスローダに突っ込まれて解析失敗となるようです。（EX != Exではじかれる）

全ファイル検索の結果では、
ご指摘に出てる、2 3 箇所の様です。

ps.
箇所数を「3」に修正しました。2012.05.15

確かに話が拡張していますが、

結論だけで言えば「EX」⇒「Ex」

だけですね。

他のファイルにもこういった部分が混在していそうで
気持ちよくはないです。。

APC ON で、同様な状況なので、
_EX:: を _Ex:: に直せば、
memcache でも、動く様な気がしてきました。。。

引用：

この部分は私もかなり気になっている部分です。

通常のメソッド呼び出しではないことは分かるのですが。。
かなり動的に呼び出していそうです。

リフレクションのような形でしょうか。。

流れとしては、やはり何を言ってもスクリプトなので、

ページアクセス⇒主要スクリプトインクルード⇒クラスローダ準備
⇒ロジックコード解析⇒不明クラスがあった場合は名前を読み出しクラスローダで動的にインクルード

だと思っているのですが。。
かつ、名前呼び出し部分でクラスローダに入れる前に
大文字小文字の吸収または何らかのキャッシング？（実行済みがあれば）
くらいまで妄想しています。

当たっている確証はまるでないですが。。

追従しました。
SC_Helper_DB_EX では、確かに、

の所で .../db/... になりますね。

では、誰が、autoload()に SC_Helper_DB_EX を渡すのか？

やはり、先の、トレース結果が知りたいです。

ご指摘の_EX は _Ex に直すとして、
今の所、現状の 2.12.3 は SC_Helper_DB_EX をautoload()に渡してはいなさそう、、、な、検証結果しか得られていませんので。。。

後少しの調査協力を頂けると助かります。

ご回答ありがとうございます。

SC_ClassAutoloader::autoloadの一部ソースを
参考してテストで行いました。

以下はテスト用のソースです。

define("CLASS_EX_REALDIR", "data/class_ex/");
define("CLASS_REALDIR", "data/class/");
$class = "SC_Helper_DB_EX";
$arrClassNamePart = explode('_', $class);
$is_ex = end($arrClassNamePart) === 'Ex';
$count = count($arrClassNamePart);
$classpath = $is_ex ? CLASS_EX_REALDIR : CLASS_REALDIR;

if (($arrClassNamePart[0] === 'GC' || $arrClassNamePart[0] === 'SC') && $arrClassNamePart[1] === 'Utils') {
$classpath .= $is_ex ? 'util_extends/' : 'util/';
} elseif ($arrClassNamePart[0] === 'SC' && $is_ex === true && $count >= 4) {
$arrClassNamePartTemp = $arrClassNamePart;
// FIXME クラスファイルのディレクトリ命名が変。変な現状に合わせて強引な処理をしてる。
$arrClassNamePartTemp[1] = $arrClassNamePartTemp[1] . '_extends';
$classpath .= strtolower(implode('/', array_slice($arrClassNamePartTemp, 1, -2))) . '/';
} elseif ($arrClassNamePart[0] === 'SC' && $is_ex === false && $count >= 3) {
$classpath .= strtolower(implode('/', array_slice($arrClassNamePart, 1, -1))) . '/';
} elseif ($arrClassNamePart[0] === 'SC') {
// 処理なし
}
// PEAR用
// FIXME トリッキー
else {
$classpath = '';
$class = str_replace('_', '/', $class);
}

$classpath .= "$class.php";
echo $classpath;


実行の結果は
data/class/helper/db/SC_Helper_DB_EX.php
です。

やはりclass/helper/dbという存在していないパスになってしまいました。

ちなみに、私はLinuxで開発していますから、大文字と小文字が区別します。

これらはGMOさんの12系モジュールを入れると自動的にインストールされるプラグインみたいですね。

当方ちょうど上記モジュールをインストールした環境がございましたのでプラグインを全て有効化した状態でカテゴリCSV登録を行ってみましたが問題ありませんでした。

不思議ですね。。。

----------------
★売れる通販サイト作ります！　========================
(株)ブラテック EC-CUBEカスタマイズサービス
http://www.bratech.co.jp/lpo/eccube.html
==============================================