FAQ
Edit report at http://pear.php.net/bugs/bug.php?id=17625&edit=1

ID: 17625
Updated by: till@php.net
Reported By: bernhard dot mayer dot hh at gmail dot com
Summary: After expiry no session data can be written
Status: Open
Type: Bug
Package: HTTP_Session2
Operating System: Win7
Package Version: 0.7.3
PHP Version: 5.3.1
Roadmap Versions:
New Comment:

So wait, you want to write data to a session after it expired? How would
you do
that with PHP $_SESSION and session_*() calls?


Previous Comments:
------------------------------------------------------------------------

[2010-07-23 13:05:04] mckenna

Description:
------------
I use this code to setup the session:
HTTP_Session2::useTransSID(false);
HTTP_Session2::useCookies(true);
HTTP_Session2::setContainer('MDB2', array(
'dsn' => &$this->db,
'table' => 'session',
'autooptimize' => true
)
);
HTTP_Session2::start('mysite');
HTTP_Session2::setExpire(3600);
HTTP_Session2::setIdle(900);

if (HTTP_Session2::isNew()) {
} else if (HTTP_Session2::isExpired()) {
HTTP_Session2::destroy();
} else if (HTTP_Session2::isIdle()) {
HTTP_Session2::destroy();
}

And after my code i'm doing this at the end
HTTP_Session2::updateIdle();

This code is mainly from the examples. As long as the session is valid
all is fine. but if the session expires there is no data found because
the timestamp is as followed: db timestamp is 1279881181 and the query
timestamp is 1279887764.

At the end if the session should be written to database the check if the
record exists found it, because only the id is checked. but the update
failed, because the timestamp.

Expected result:
----------------
Using a new session or a cleared old session.

Actual result:
--------------
Every call result in a clear session, and the data is never saved.

------------------------------------------------------------------------

Search Discussions

  • Till at Jul 26, 2010 at 7:24 pm
    Edit report at http://pear.php.net/bugs/bug.php?id=17625&edit=1

    ID: 17625
    Updated by: till@php.net
    Reported By: bernhard dot mayer dot hh at gmail dot com
    Summary: After expiry no session data can be written
    Status: Open
    Type: Bug
    Package: HTTP_Session2
    Operating System: Win7
    Package Version: 0.7.3
    PHP Version: 5.3.1
    -Assigned To:
    +Assigned To: till
    Roadmap Versions:
    New Comment:

    -Assigned To:
    +Assigned To: till



    Previous Comments:
    ------------------------------------------------------------------------

    [2010-07-26 19:24:29] till

    So wait, you want to write data to a session after it expired? How would
    you do
    that with PHP $_SESSION and session_*() calls?

    ------------------------------------------------------------------------

    [2010-07-23 13:05:04] mckenna

    Description:
    ------------
    I use this code to setup the session:
    HTTP_Session2::useTransSID(false);
    HTTP_Session2::useCookies(true);
    HTTP_Session2::setContainer('MDB2', array(
    'dsn' => &$this->db,
    'table' => 'session',
    'autooptimize' => true
    )
    );
    HTTP_Session2::start('mysite');
    HTTP_Session2::setExpire(3600);
    HTTP_Session2::setIdle(900);

    if (HTTP_Session2::isNew()) {
    } else if (HTTP_Session2::isExpired()) {
    HTTP_Session2::destroy();
    } else if (HTTP_Session2::isIdle()) {
    HTTP_Session2::destroy();
    }

    And after my code i'm doing this at the end
    HTTP_Session2::updateIdle();

    This code is mainly from the examples. As long as the session is valid
    all is fine. but if the session expires there is no data found because
    the timestamp is as followed: db timestamp is 1279881181 and the query
    timestamp is 1279887764.

    At the end if the session should be written to database the check if the
    record exists found it, because only the id is checked. but the update
    failed, because the timestamp.

    Expected result:
    ----------------
    Using a new session or a cleared old session.

    Actual result:
    --------------
    Every call result in a clear session, and the data is never saved.

    ------------------------------------------------------------------------
  • Bernhard Mayer Hh at Jul 26, 2010 at 8:24 pm
    Edit report at http://pear.php.net/bugs/bug.php?id=17625&edit=1

    ID: 17625
    Comment by: bernhard.mayer.hh@gmail.com
    Reported By: bernhard dot mayer dot hh at gmail dot com
    Summary: After expiry no session data can be written
    Status: Assigned
    Type: Bug
    Package: HTTP_Session2
    Operating System: Win7
    Package Version: 0.7.3
    PHP Version: 5.3.1
    Assigned To: till
    Roadmap Versions:
    New Comment:

    I always use $_SESSION, but i don't want to write to a expired session.
    The problem is, the session seems to be expired and the db record is
    still there. the destroy doesn't deleted it. the other methods from the
    mdb2 module finds this record and tries to write to db. but they didn't
    use a new session, they want to update the old with a other timestamp
    that prevents the update. so every new call to pages ends in a session
    that can't be saved.

    or maybe i'm using http_session2 in a wrong way, its not impossible :)


    Previous Comments:
    ------------------------------------------------------------------------

    [2010-07-26 19:24:34] till

    -Assigned To:
    +Assigned To: till


    ------------------------------------------------------------------------

    [2010-07-26 19:24:29] till

    So wait, you want to write data to a session after it expired? How would
    you do
    that with PHP $_SESSION and session_*() calls?

    ------------------------------------------------------------------------

    [2010-07-23 13:05:04] mckenna

    Description:
    ------------
    I use this code to setup the session:
    HTTP_Session2::useTransSID(false);
    HTTP_Session2::useCookies(true);
    HTTP_Session2::setContainer('MDB2', array(
    'dsn' => &$this->db,
    'table' => 'session',
    'autooptimize' => true
    )
    );
    HTTP_Session2::start('mysite');
    HTTP_Session2::setExpire(3600);
    HTTP_Session2::setIdle(900);

    if (HTTP_Session2::isNew()) {
    } else if (HTTP_Session2::isExpired()) {
    HTTP_Session2::destroy();
    } else if (HTTP_Session2::isIdle()) {
    HTTP_Session2::destroy();
    }

    And after my code i'm doing this at the end
    HTTP_Session2::updateIdle();

    This code is mainly from the examples. As long as the session is valid
    all is fine. but if the session expires there is no data found because
    the timestamp is as followed: db timestamp is 1279881181 and the query
    timestamp is 1279887764.

    At the end if the session should be written to database the check if the
    record exists found it, because only the id is checked. but the update
    failed, because the timestamp.

    Expected result:
    ----------------
    Using a new session or a cleared old session.

    Actual result:
    --------------
    Every call result in a clear session, and the data is never saved.

    ------------------------------------------------------------------------
  • Till at Jul 26, 2010 at 8:38 pm
    Edit report at http://pear.php.net/bugs/bug.php?id=17625&edit=1

    ID: 17625
    Updated by: till@php.net
    Reported By: bernhard dot mayer dot hh at gmail dot com
    Summary: After expiry no session data can be written
    Status: Assigned
    Type: Bug
    Package: HTTP_Session2
    Operating System: Win7
    Package Version: 0.7.3
    PHP Version: 5.3.1
    Assigned To: till
    Roadmap Versions:
    New Comment:

    Afaik, HTTP_Session2::destroy() (which wraps session_destroy()) only
    removes references, it doesn't create actual data.

    So for example, even if you used straight PHP sessions this wouldn't
    happen.
    The files would still be there in (session.save_dir) until the garbage
    collector
    is run.

    Check:
    HTTP_Session2::setGcMaxLifetime()
    HTTP_Session2::setGcProbability()

    http://svn.php.net/viewvc/pear/packages/HTTP_Session2/trunk/HTTP/Sessio
    n2.php?revision=267739&view=markup


    Previous Comments:
    ------------------------------------------------------------------------

    [2010-07-26 20:23:58] mckenna

    I always use $_SESSION, but i don't want to write to a expired session.
    The problem is, the session seems to be expired and the db record is
    still there. the destroy doesn't deleted it. the other methods from the
    mdb2 module finds this record and tries to write to db. but they didn't
    use a new session, they want to update the old with a other timestamp
    that prevents the update. so every new call to pages ends in a session
    that can't be saved.

    or maybe i'm using http_session2 in a wrong way, its not impossible :)

    ------------------------------------------------------------------------

    [2010-07-26 19:24:34] till

    -Assigned To:
    +Assigned To: till


    ------------------------------------------------------------------------

    [2010-07-26 19:24:29] till

    So wait, you want to write data to a session after it expired? How would
    you do
    that with PHP $_SESSION and session_*() calls?

    ------------------------------------------------------------------------

    [2010-07-23 13:05:04] mckenna

    Description:
    ------------
    I use this code to setup the session:
    HTTP_Session2::useTransSID(false);
    HTTP_Session2::useCookies(true);
    HTTP_Session2::setContainer('MDB2', array(
    'dsn' => &$this->db,
    'table' => 'session',
    'autooptimize' => true
    )
    );
    HTTP_Session2::start('mysite');
    HTTP_Session2::setExpire(3600);
    HTTP_Session2::setIdle(900);

    if (HTTP_Session2::isNew()) {
    } else if (HTTP_Session2::isExpired()) {
    HTTP_Session2::destroy();
    } else if (HTTP_Session2::isIdle()) {
    HTTP_Session2::destroy();
    }

    And after my code i'm doing this at the end
    HTTP_Session2::updateIdle();

    This code is mainly from the examples. As long as the session is valid
    all is fine. but if the session expires there is no data found because
    the timestamp is as followed: db timestamp is 1279881181 and the query
    timestamp is 1279887764.

    At the end if the session should be written to database the check if the
    record exists found it, because only the id is checked. but the update
    failed, because the timestamp.

    Expected result:
    ----------------
    Using a new session or a cleared old session.

    Actual result:
    --------------
    Every call result in a clear session, and the data is never saved.

    ------------------------------------------------------------------------
  • Till at Jul 26, 2010 at 8:40 pm
    Edit report at http://pear.php.net/bugs/bug.php?id=17625&edit=1

    ID: 17625
    Updated by: till@php.net
    Reported By: bernhard dot mayer dot hh at gmail dot com
    Summary: After expiry no session data can be written
    Status: Assigned
    Type: Bug
    Package: HTTP_Session2
    Operating System: Win7
    Package Version: 0.7.3
    PHP Version: 5.3.1
    Assigned To: till
    Roadmap Versions:
    New Comment:

    Sorry, to clarify:
    Afaik, HTTP_Session2::destroy() (which wraps session_destroy())
    only removes references, it doesn't create actual data.
    ... doesn't delete actual data.


    Previous Comments:
    ------------------------------------------------------------------------

    [2010-07-26 20:38:48] till

    Afaik, HTTP_Session2::destroy() (which wraps session_destroy()) only
    removes references, it doesn't create actual data.

    So for example, even if you used straight PHP sessions this wouldn't
    happen.
    The files would still be there in (session.save_dir) until the garbage
    collector
    is run.

    Check:
    HTTP_Session2::setGcMaxLifetime()
    HTTP_Session2::setGcProbability()

    http://svn.php.net/viewvc/pear/packages/HTTP_Session2/trunk/HTTP/Sessio
    n2.php?revision=267739&view=markup

    ------------------------------------------------------------------------

    [2010-07-26 20:23:58] mckenna

    I always use $_SESSION, but i don't want to write to a expired session.
    The problem is, the session seems to be expired and the db record is
    still there. the destroy doesn't deleted it. the other methods from the
    mdb2 module finds this record and tries to write to db. but they didn't
    use a new session, they want to update the old with a other timestamp
    that prevents the update. so every new call to pages ends in a session
    that can't be saved.

    or maybe i'm using http_session2 in a wrong way, its not impossible :)

    ------------------------------------------------------------------------

    [2010-07-26 19:24:34] till

    -Assigned To:
    +Assigned To: till


    ------------------------------------------------------------------------

    [2010-07-26 19:24:29] till

    So wait, you want to write data to a session after it expired? How would
    you do
    that with PHP $_SESSION and session_*() calls?

    ------------------------------------------------------------------------

    [2010-07-23 13:05:04] mckenna

    Description:
    ------------
    I use this code to setup the session:
    HTTP_Session2::useTransSID(false);
    HTTP_Session2::useCookies(true);
    HTTP_Session2::setContainer('MDB2', array(
    'dsn' => &$this->db,
    'table' => 'session',
    'autooptimize' => true
    )
    );
    HTTP_Session2::start('mysite');
    HTTP_Session2::setExpire(3600);
    HTTP_Session2::setIdle(900);

    if (HTTP_Session2::isNew()) {
    } else if (HTTP_Session2::isExpired()) {
    HTTP_Session2::destroy();
    } else if (HTTP_Session2::isIdle()) {
    HTTP_Session2::destroy();
    }

    And after my code i'm doing this at the end
    HTTP_Session2::updateIdle();

    This code is mainly from the examples. As long as the session is valid
    all is fine. but if the session expires there is no data found because
    the timestamp is as followed: db timestamp is 1279881181 and the query
    timestamp is 1279887764.

    At the end if the session should be written to database the check if the
    record exists found it, because only the id is checked. but the update
    failed, because the timestamp.

    Expected result:
    ----------------
    Using a new session or a cleared old session.

    Actual result:
    --------------
    Every call result in a clear session, and the data is never saved.

    ------------------------------------------------------------------------
  • Bernhard Mayer Hh at Jul 26, 2010 at 8:48 pm
    Edit report at http://pear.php.net/bugs/bug.php?id=17625&edit=1

    ID: 17625
    Comment by: bernhard.mayer.hh@gmail.com
    Reported By: bernhard dot mayer dot hh at gmail dot com
    Summary: After expiry no session data can be written
    Status: Assigned
    Type: Bug
    Package: HTTP_Session2
    Operating System: Win7
    Package Version: 0.7.3
    PHP Version: 5.3.1
    Assigned To: till
    Roadmap Versions:
    New Comment:

    yes, but i use the mdb2 container which register a destroy function to
    session_destroy call, or am i wrong? and this function should delete the
    session data?

    http://svn.php.net/viewvc/pear/packages/HTTP_Session2/trunk/HTTP/Session2/Container/MDB2.php?view=markup

    at line 261.


    Previous Comments:
    ------------------------------------------------------------------------

    [2010-07-26 20:39:59] till

    Sorry, to clarify:
    Afaik, HTTP_Session2::destroy() (which wraps session_destroy())
    only removes references, it doesn't create actual data.
    ... doesn't delete actual data.

    ------------------------------------------------------------------------

    [2010-07-26 20:38:48] till

    Afaik, HTTP_Session2::destroy() (which wraps session_destroy()) only
    removes references, it doesn't create actual data.

    So for example, even if you used straight PHP sessions this wouldn't
    happen.
    The files would still be there in (session.save_dir) until the garbage
    collector
    is run.

    Check:
    HTTP_Session2::setGcMaxLifetime()
    HTTP_Session2::setGcProbability()

    http://svn.php.net/viewvc/pear/packages/HTTP_Session2/trunk/HTTP/Sessio
    n2.php?revision=267739&view=markup

    ------------------------------------------------------------------------

    [2010-07-26 20:23:58] mckenna

    I always use $_SESSION, but i don't want to write to a expired session.
    The problem is, the session seems to be expired and the db record is
    still there. the destroy doesn't deleted it. the other methods from the
    mdb2 module finds this record and tries to write to db. but they didn't
    use a new session, they want to update the old with a other timestamp
    that prevents the update. so every new call to pages ends in a session
    that can't be saved.

    or maybe i'm using http_session2 in a wrong way, its not impossible :)

    ------------------------------------------------------------------------

    [2010-07-26 19:24:34] till

    -Assigned To:
    +Assigned To: till


    ------------------------------------------------------------------------

    [2010-07-26 19:24:29] till

    So wait, you want to write data to a session after it expired? How would
    you do
    that with PHP $_SESSION and session_*() calls?

    ------------------------------------------------------------------------

    The remainder of the comments for this report are too long. To view
    the rest of the comments, please view the bug report online at
    http://pear.php.net/bugs/bug.php?id=17625
  • Till at Jul 28, 2010 at 4:03 pm
    Edit report at http://pear.php.net/bugs/bug.php?id=17625&edit=1

    ID: 17625
    Updated by: till@php.net
    Reported By: bernhard dot mayer dot hh at gmail dot com
    Summary: After expiry no session data can be written
    Status: Assigned
    Type: Bug
    Package: HTTP_Session2
    Operating System: Win7
    Package Version: 0.7.3
    PHP Version: 5.3.1
    Assigned To: till
    Roadmap Versions:
    New Comment:

    Yes, but here's your misunderstanding:

    1) HTTP_Session2 registers a new session-handler, in your case the
    MDB2-
    based one.

    2) This session-handler is configured through regular PHP settings
    (session.*), including garbage collection (gc) - e.g. probablity and
    lifetime.
    Depending on your settings (which I assume you didn't really touch), the

    garbage collection is run.

    3) The function HTTP_Session2::destroy() has nothing to do with that in
    the
    container. The one in the container is configured/ran using session.gc_*
    stuff,
    or using HTTP_Session2::setGcMaxLifeTime() and
    HTTP_Session2::setGcProbability() (PROBABILITY) ;-)

    I hope this clears things up.


    Previous Comments:
    ------------------------------------------------------------------------

    [2010-07-26 20:48:55] mckenna

    yes, but i use the mdb2 container which register a destroy function to
    session_destroy call, or am i wrong? and this function should delete the
    session data?

    http://svn.php.net/viewvc/pear/packages/HTTP_Session2/trunk/HTTP/Session2/Container/MDB2.php?view=markup

    at line 261.

    ------------------------------------------------------------------------

    [2010-07-26 20:39:59] till

    Sorry, to clarify:
    Afaik, HTTP_Session2::destroy() (which wraps session_destroy())
    only removes references, it doesn't create actual data.
    ... doesn't delete actual data.

    ------------------------------------------------------------------------

    [2010-07-26 20:38:48] till

    Afaik, HTTP_Session2::destroy() (which wraps session_destroy()) only
    removes references, it doesn't create actual data.

    So for example, even if you used straight PHP sessions this wouldn't
    happen.
    The files would still be there in (session.save_dir) until the garbage
    collector
    is run.

    Check:
    HTTP_Session2::setGcMaxLifetime()
    HTTP_Session2::setGcProbability()

    http://svn.php.net/viewvc/pear/packages/HTTP_Session2/trunk/HTTP/Sessio
    n2.php?revision=267739&view=markup

    ------------------------------------------------------------------------

    [2010-07-26 20:23:58] mckenna

    I always use $_SESSION, but i don't want to write to a expired session.
    The problem is, the session seems to be expired and the db record is
    still there. the destroy doesn't deleted it. the other methods from the
    mdb2 module finds this record and tries to write to db. but they didn't
    use a new session, they want to update the old with a other timestamp
    that prevents the update. so every new call to pages ends in a session
    that can't be saved.

    or maybe i'm using http_session2 in a wrong way, its not impossible :)

    ------------------------------------------------------------------------

    [2010-07-26 19:24:34] till

    -Assigned To:
    +Assigned To: till


    ------------------------------------------------------------------------

    The remainder of the comments for this report are too long. To view
    the rest of the comments, please view the bug report online at
    http://pear.php.net/bugs/bug.php?id=17625
  • Till at Jul 28, 2010 at 4:04 pm
    Edit report at http://pear.php.net/bugs/bug.php?id=17625&edit=1

    ID: 17625
    Updated by: till@php.net
    Reported By: bernhard dot mayer dot hh at gmail dot com
    Summary: After expiry no session data can be written
    -Status: Assigned
    +Status: Bogus
    Type: Bug
    Package: HTTP_Session2
    Operating System: Win7
    Package Version: 0.7.3
    PHP Version: 5.3.1
    Assigned To: till
    Roadmap Versions:
    New Comment:

    -Status: Assigned
    +Status: Bogus
    Thank you for taking the time to write to us, but this is not
    a bug.

    Btw, I totally agree - this could be better documented. If you have the
    urge to
    contribute something, let me know. Feel free to re-open with some info,
    or
    whatever.


    Previous Comments:
    ------------------------------------------------------------------------

    [2010-07-28 16:03:36] till

    Yes, but here's your misunderstanding:

    1) HTTP_Session2 registers a new session-handler, in your case the
    MDB2-
    based one.

    2) This session-handler is configured through regular PHP settings
    (session.*), including garbage collection (gc) - e.g. probablity and
    lifetime.
    Depending on your settings (which I assume you didn't really touch), the

    garbage collection is run.

    3) The function HTTP_Session2::destroy() has nothing to do with that in
    the
    container. The one in the container is configured/ran using session.gc_*
    stuff,
    or using HTTP_Session2::setGcMaxLifeTime() and
    HTTP_Session2::setGcProbability() (PROBABILITY) ;-)

    I hope this clears things up.

    ------------------------------------------------------------------------

    [2010-07-26 20:48:55] mckenna

    yes, but i use the mdb2 container which register a destroy function to
    session_destroy call, or am i wrong? and this function should delete the
    session data?

    http://svn.php.net/viewvc/pear/packages/HTTP_Session2/trunk/HTTP/Session2/Container/MDB2.php?view=markup

    at line 261.

    ------------------------------------------------------------------------

    [2010-07-26 20:39:59] till

    Sorry, to clarify:
    Afaik, HTTP_Session2::destroy() (which wraps session_destroy())
    only removes references, it doesn't create actual data.
    ... doesn't delete actual data.

    ------------------------------------------------------------------------

    [2010-07-26 20:38:48] till

    Afaik, HTTP_Session2::destroy() (which wraps session_destroy()) only
    removes references, it doesn't create actual data.

    So for example, even if you used straight PHP sessions this wouldn't
    happen.
    The files would still be there in (session.save_dir) until the garbage
    collector
    is run.

    Check:
    HTTP_Session2::setGcMaxLifetime()
    HTTP_Session2::setGcProbability()

    http://svn.php.net/viewvc/pear/packages/HTTP_Session2/trunk/HTTP/Sessio
    n2.php?revision=267739&view=markup

    ------------------------------------------------------------------------

    [2010-07-26 20:23:58] mckenna

    I always use $_SESSION, but i don't want to write to a expired session.
    The problem is, the session seems to be expired and the db record is
    still there. the destroy doesn't deleted it. the other methods from the
    mdb2 module finds this record and tries to write to db. but they didn't
    use a new session, they want to update the old with a other timestamp
    that prevents the update. so every new call to pages ends in a session
    that can't be saved.

    or maybe i'm using http_session2 in a wrong way, its not impossible :)

    ------------------------------------------------------------------------

    The remainder of the comments for this report are too long. To view
    the rest of the comments, please view the bug report online at
    http://pear.php.net/bugs/bug.php?id=17625
  • Bernhard Mayer Hh at Jul 29, 2010 at 7:13 am
    Edit report at http://pear.php.net/bugs/bug.php?id=17625&edit=1

    ID: 17625
    Updated by: bernhard.mayer.hh@gmail.com
    Reported By: bernhard dot mayer dot hh at gmail dot com
    Summary: After expiry no session data can be written
    Status: Bogus
    Type: Bug
    Package: HTTP_Session2
    Operating System: Win7
    Package Version: 0.7.3
    PHP Version: 5.3.1
    Assigned To: till
    Roadmap Versions:
    New Comment:

    Ok, thanks for your explanation. That helped and i figured something out
    that was my misstake. I used the pause function to update the session
    data, i thought. but pause wrote the data and closed the db connection.
    And i used pause in my code before i called updateidle. So the session
    was always idle after the idle time from the session start. That was one
    of my problems and the gc functions cleared some of the rest.

    Thanks!


    Previous Comments:
    ------------------------------------------------------------------------

    [2010-07-28 16:04:47] till

    -Status: Assigned
    +Status: Bogus
    Thank you for taking the time to write to us, but this is not
    a bug.

    Btw, I totally agree - this could be better documented. If you have the
    urge to
    contribute something, let me know. Feel free to re-open with some info,
    or
    whatever.

    ------------------------------------------------------------------------

    [2010-07-28 16:03:36] till

    Yes, but here's your misunderstanding:

    1) HTTP_Session2 registers a new session-handler, in your case the
    MDB2-
    based one.

    2) This session-handler is configured through regular PHP settings
    (session.*), including garbage collection (gc) - e.g. probablity and
    lifetime.
    Depending on your settings (which I assume you didn't really touch), the

    garbage collection is run.

    3) The function HTTP_Session2::destroy() has nothing to do with that in
    the
    container. The one in the container is configured/ran using session.gc_*
    stuff,
    or using HTTP_Session2::setGcMaxLifeTime() and
    HTTP_Session2::setGcProbability() (PROBABILITY) ;-)

    I hope this clears things up.

    ------------------------------------------------------------------------

    [2010-07-26 20:48:55] mckenna

    yes, but i use the mdb2 container which register a destroy function to
    session_destroy call, or am i wrong? and this function should delete the
    session data?

    http://svn.php.net/viewvc/pear/packages/HTTP_Session2/trunk/HTTP/Session2/Container/MDB2.php?view=markup

    at line 261.

    ------------------------------------------------------------------------

    [2010-07-26 20:39:59] till

    Sorry, to clarify:
    Afaik, HTTP_Session2::destroy() (which wraps session_destroy())
    only removes references, it doesn't create actual data.
    ... doesn't delete actual data.

    ------------------------------------------------------------------------

    [2010-07-26 20:38:48] till

    Afaik, HTTP_Session2::destroy() (which wraps session_destroy()) only
    removes references, it doesn't create actual data.

    So for example, even if you used straight PHP sessions this wouldn't
    happen.
    The files would still be there in (session.save_dir) until the garbage
    collector
    is run.

    Check:
    HTTP_Session2::setGcMaxLifetime()
    HTTP_Session2::setGcProbability()

    http://svn.php.net/viewvc/pear/packages/HTTP_Session2/trunk/HTTP/Sessio
    n2.php?revision=267739&view=markup

    ------------------------------------------------------------------------

    The remainder of the comments for this report are too long. To view
    the rest of the comments, please view the bug report online at
    http://pear.php.net/bugs/bug.php?id=17625
  • Bernhard Mayer Hh at Jul 30, 2010 at 11:57 am
    Edit report at http://pear.php.net/bugs/bug.php?id=17625&edit=1

    ID: 17625
    Comment by: bernhard.mayer.hh@gmail.com
    Reported By: bernhard dot mayer dot hh at gmail dot com
    Summary: After expiry no session data can be written
    Status: Bogus
    Type: Bug
    Package: HTTP_Session2
    Operating System: Win7
    Package Version: 0.7.3
    PHP Version: 5.3.1
    Assigned To: till
    Roadmap Versions:
    New Comment:

    Still one of the problem resists. The Session seems to be expired, but
    the module can't update the record. here is some logging:

    13:43:40 Open...
    13:43:40 Connect...
    13:43:40 Read...
    SELECT data FROM session WHERE id = 'b38aa7b96aff956da71878556f6eea42'
    AND expiry >= 1280490220
    Result:
    Empty result...
    13:43:40 Update Idle...
    13:43:40 Write...
    13:43:40 Check...
    SELECT COUNT(id) FROM session WHERE id =
    'b38aa7b96aff956da71878556f6eea42'
    13:43:40 Update...
    UPDATE session SET expiry = 1280491660, data = '...' AND expiry >=
    1280490220
    Affected Rows: 0
    13:43:40 Close...

    The database field expiry has the value 1280490046 for this record.
    As you can see the read method didn't found the record and result in a
    empty session.
    The write method checks for the session, found it and tries to update
    it, but can't update it.

    I don't know why this happens, but this is the core problem of all my
    problems.

    btw the write method at line ~258 should use the exec method of mdb2.
    currently it uses the query method. this way you can't see the affected
    rows. and the statements are only inserts or updates at this point.


    Previous Comments:
    ------------------------------------------------------------------------

    [2010-07-29 07:13:12] mckenna

    Ok, thanks for your explanation. That helped and i figured something out
    that was my misstake. I used the pause function to update the session
    data, i thought. but pause wrote the data and closed the db connection.
    And i used pause in my code before i called updateidle. So the session
    was always idle after the idle time from the session start. That was one
    of my problems and the gc functions cleared some of the rest.

    Thanks!

    ------------------------------------------------------------------------

    [2010-07-28 16:04:47] till

    -Status: Assigned
    +Status: Bogus
    Thank you for taking the time to write to us, but this is not
    a bug.

    Btw, I totally agree - this could be better documented. If you have the
    urge to
    contribute something, let me know. Feel free to re-open with some info,
    or
    whatever.

    ------------------------------------------------------------------------

    [2010-07-28 16:03:36] till

    Yes, but here's your misunderstanding:

    1) HTTP_Session2 registers a new session-handler, in your case the
    MDB2-
    based one.

    2) This session-handler is configured through regular PHP settings
    (session.*), including garbage collection (gc) - e.g. probablity and
    lifetime.
    Depending on your settings (which I assume you didn't really touch), the

    garbage collection is run.

    3) The function HTTP_Session2::destroy() has nothing to do with that in
    the
    container. The one in the container is configured/ran using session.gc_*
    stuff,
    or using HTTP_Session2::setGcMaxLifeTime() and
    HTTP_Session2::setGcProbability() (PROBABILITY) ;-)

    I hope this clears things up.

    ------------------------------------------------------------------------

    [2010-07-26 20:48:55] mckenna

    yes, but i use the mdb2 container which register a destroy function to
    session_destroy call, or am i wrong? and this function should delete the
    session data?

    http://svn.php.net/viewvc/pear/packages/HTTP_Session2/trunk/HTTP/Session2/Container/MDB2.php?view=markup

    at line 261.

    ------------------------------------------------------------------------

    [2010-07-26 20:39:59] till

    Sorry, to clarify:
    Afaik, HTTP_Session2::destroy() (which wraps session_destroy())
    only removes references, it doesn't create actual data.
    ... doesn't delete actual data.

    ------------------------------------------------------------------------

    The remainder of the comments for this report are too long. To view
    the rest of the comments, please view the bug report online at
    http://pear.php.net/bugs/bug.php?id=17625
  • Till at Jul 31, 2010 at 10:54 pm
    Edit report at http://pear.php.net/bugs/bug.php?id=17625&edit=1

    ID: 17625
    Updated by: till@php.net
    Reported By: bernhard dot mayer dot hh at gmail dot com
    Summary: After expiry no session data can be written
    -Status: Bogus
    +Status: Feedback
    Type: Bug
    Package: HTTP_Session2
    Operating System: Win7
    Package Version: 0.7.3
    PHP Version: 5.3.1
    Assigned To: till
    Roadmap Versions:
    New Comment:

    -Status: Bogus
    +Status: Feedback
    Can you open a separate issue for query() vs. exec() - with a patch if
    possible.

    I'll think about your other issue, I need a fresh set of eyes on this.


    Previous Comments:
    ------------------------------------------------------------------------

    [2010-07-30 11:57:53] mckenna

    Still one of the problem resists. The Session seems to be expired, but
    the module can't update the record. here is some logging:

    13:43:40 Open...
    13:43:40 Connect...
    13:43:40 Read...
    SELECT data FROM session WHERE id = 'b38aa7b96aff956da71878556f6eea42'
    AND expiry >= 1280490220
    Result:
    Empty result...
    13:43:40 Update Idle...
    13:43:40 Write...
    13:43:40 Check...
    SELECT COUNT(id) FROM session WHERE id =
    'b38aa7b96aff956da71878556f6eea42'
    13:43:40 Update...
    UPDATE session SET expiry = 1280491660, data = '...' AND expiry >=
    1280490220
    Affected Rows: 0
    13:43:40 Close...

    The database field expiry has the value 1280490046 for this record.
    As you can see the read method didn't found the record and result in a
    empty session.
    The write method checks for the session, found it and tries to update
    it, but can't update it.

    I don't know why this happens, but this is the core problem of all my
    problems.

    btw the write method at line ~258 should use the exec method of mdb2.
    currently it uses the query method. this way you can't see the affected
    rows. and the statements are only inserts or updates at this point.

    ------------------------------------------------------------------------

    [2010-07-29 07:13:12] mckenna

    Ok, thanks for your explanation. That helped and i figured something out
    that was my misstake. I used the pause function to update the session
    data, i thought. but pause wrote the data and closed the db connection.
    And i used pause in my code before i called updateidle. So the session
    was always idle after the idle time from the session start. That was one
    of my problems and the gc functions cleared some of the rest.

    Thanks!

    ------------------------------------------------------------------------

    [2010-07-28 16:04:47] till

    -Status: Assigned
    +Status: Bogus
    Thank you for taking the time to write to us, but this is not
    a bug.

    Btw, I totally agree - this could be better documented. If you have the
    urge to
    contribute something, let me know. Feel free to re-open with some info,
    or
    whatever.

    ------------------------------------------------------------------------

    [2010-07-28 16:03:36] till

    Yes, but here's your misunderstanding:

    1) HTTP_Session2 registers a new session-handler, in your case the
    MDB2-
    based one.

    2) This session-handler is configured through regular PHP settings
    (session.*), including garbage collection (gc) - e.g. probablity and
    lifetime.
    Depending on your settings (which I assume you didn't really touch), the

    garbage collection is run.

    3) The function HTTP_Session2::destroy() has nothing to do with that in
    the
    container. The one in the container is configured/ran using session.gc_*
    stuff,
    or using HTTP_Session2::setGcMaxLifeTime() and
    HTTP_Session2::setGcProbability() (PROBABILITY) ;-)

    I hope this clears things up.

    ------------------------------------------------------------------------

    [2010-07-26 20:48:55] mckenna

    yes, but i use the mdb2 container which register a destroy function to
    session_destroy call, or am i wrong? and this function should delete the
    session data?

    http://svn.php.net/viewvc/pear/packages/HTTP_Session2/trunk/HTTP/Session2/Container/MDB2.php?view=markup

    at line 261.

    ------------------------------------------------------------------------

    The remainder of the comments for this report are too long. To view
    the rest of the comments, please view the bug report online at
    http://pear.php.net/bugs/bug.php?id=17625

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppear-bugs @
categoriesphp
postedJul 26, '10 at 7:24p
activeJul 31, '10 at 10:54p
posts11
users3
websitepear.php.net

People

Translate

site design / logo © 2021 Grokbase