views:

97

answers:

3

I'm experimenting with PHP's session_set_save_handler and I'd like to use a PDO connection to store session data.

I have this function as a callback for write actions:

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());
    }
}

The first two log messages always show up, but the third one right after $stmt = $GLOBALS['db']->prepare($sql) never makes it to the log file and there's no trace of an exception either.

The sessions db table remains empty.

The log message from the _close callback is always present.

Here's how I connect to the database:

$db = new PDO('mysql:host=' . DBHOST . ';dbname=' . DBNAME, DBUSER, DBPASS);
$db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

I have PHP 5.2.10.

I tried to simply run $GLOBALS['db']->exec($sql) with a "manually prepared" $sql content, but it still failed silently. The query itself is all right I was able to execute it via the db console.


Edit:

After VolkerK has identified the problem I've found this article which explains the reason behind this weird phenomena. Perhaps it could be informative to others as well.


2nd edit:

The least painful, magic solution is that I had to add the below function call to the very end of my front controller (the main index.php) file:

session_write_close();
+2  A: 

My bets are on: $GLOBALS['db'] is not set or not an instance of pdo (anymore?) and therefor a PHP Fatal error: Call to a member function prepare() on a non-object occurs and php bails out.

$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.');
if ( !isset($GLOBALS['db']) ) {
  logger('there is no globals[db]');
  return;
}
else if ( !is_object($GLOBALS['db']) ) {
  logger('globals[db] is not an object');
  return;
}
else if ( !($GLOBALS['db'] instanceof PDO) ) {
  logger('globals[db] is not a PDO object');
  return;
}
else {
  logger('globals[db] seems ok');
}

$stmt = $GLOBALS['db']->prepare($sql);
logger('This never gets logged! :(');
VolkerK
We have a winner here! :) Indeed I got the "there is no globals[db]" message logged. I'm not sure why is it so, but it's a very useful clue. Thank you very much your kind help it is really appreciated.
Wabbitseason
A: 

Perhaps PDO doesn't recognize the REPLACE INTO syntax. If the underlying DB access library doesn't support prepared statements directly, PDO emulates them, and may not have REPLACE INTO in its list of possible statement types.

Try checking $stmt->errorCode() immediately after the prepare call?

If this is mysql, you could try rewriting the prepared statement as follows:

INSERT INTO sessions (id, access, data)
VALUES(:id, :access, :data)
ON DUPLICATE KEY UDPATE
    access=VALUES(access), data=VALUES(data);

and see if that gets you any farther.

Marc B
Indeed I'm using MySQL 5.1, but rewriting the query didn't help. I even tried to rewrite it as a completely harmless and useless `SELECT`, and it still stopped after the `prepare` without any notification. Because of this I haven't been able to check the `errorCode`. This is really weird.
Wabbitseason
A: 

I feel like resource data types can't be accessed via $GLOBALS[]. Something about the way references are handled or something. If you're in the mood to humor my hunch try this for your function declaration:

function _write($id, $data) {
    global $db;
    logger('_WRITE ' . $id . ' ' . $data);
    try {

And instead of this:

$stmt = $GLOBALS['db']->prepare($sql);

try

$stmt = $db->prepare($sql);

You could also try catching plain old Exceptions instead of PDOExceptions; it might be getting caught up on that.

Hope this helps!

mattbasta
There's absolutely no difference between using `global` and referring to a global variable with `$GLOBAL`. Also the plain vanilla `Exception` didn't make any difference. Thanks for trying to help though.
Wabbitseason