【发布时间】:2010-04-07 20:56:36
【问题描述】:
我正在试验 PHP 的 session_set_save_handler,我想使用 PDO 连接来存储会话数据。
我有这个函数作为写操作的回调:
function _write($id, $data) {
logger('_WRITE ' . $id . ' ' . $data);
try {
$access = time();
$sql = 'REPLACE INTO sessions SET id=:id, access=:access, data=:data';
logger('This is the last line in this function that appears in the log.');
$stmt = $GLOBALS['db']->prepare($sql);
logger('This never gets logged! :(');
$stmt->bindParam(':id', $id, PDO::PARAM_STR);
$stmt->bindParam(':access', $access, PDO::PARAM_INT);
$stmt->bindParam(':data', $data, PDO::PARAM_STR);
$stmt->execute();
$stmt->closeCursor();
return true;
} catch (PDOException $e) {
logger('This is never executed.');
logger($e->getTraceAsString());
}
}
前两条日志消息始终显示,但紧随$stmt = $GLOBALS['db']->prepare($sql) 之后的第三条消息从未出现在日志文件中,也没有异常的痕迹。
sessions db 表保持为空。
来自_close 回调的日志消息始终存在。
这是我连接到数据库的方式:
$db = new PDO('mysql:host=' . DBHOST . ';dbname=' . DBNAME, DBUSER, DBPASS);
$db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
我有 PHP 5.2.10。
我尝试使用“手动准备的”$sql 内容简单地运行$GLOBALS['db']->exec($sql),但它仍然默默地失败了。查询本身没问题,我可以通过 db 控制台执行它。
编辑:
在 VolkerK 发现问题后,我发现了this article,这解释了这种奇怪现象背后的原因。也许它也可以为其他人提供信息。
第二次编辑:
最不痛苦、最神奇的解决方案是我必须将以下函数调用添加到我的前端控制器(主 index.php)文件的最后:
session_write_close();
【问题讨论】:
-
确保您已启用
error_reporting(-1) -
@Gordon:什么都没有改变。我已经有了这个设置:
error_reporting(E_ALL|E_STRICT) -
好的。顺便说一句 -1 和你的设置一样,只是更方便记住;)
标签: php session pdo session-set-save-handler