Edit report at https://bugs.php.net/bug.php?id=68331&edit=1
ID: 68331
Updated by: yohgaki@php.net
Reported by: mark at grooveshark dot com
Summary: Session custom storage callable functions not being
called
-Status: Not a bug
+Status: Re-Opened
-Type: Bug
+Type: Feature/Change Request
Package: Session related
Operating System: All
PHP Version: 5.6.2
Block user comment: N
Private report: N
New Comment:
I don't understand the reason why you need "write" even when session data was not
changed at all.
BTW, I was suggesting "update" handler for the RFC introduce this feature, but there were
objection and withdrawned.
I may try to add user space "update" again.
Previous Comments:
------------------------------------------------------------------------
[2014-11-04 22:35:27] james at grooveshark dot com
> The RFC reintroduces the idea of lazy writing as an optional feature > so when that is in
> then you'll be able to (not) use it.
That's not a problem. Its fine for it to be optional but in 5.6 its NOT optional and
there's no way to turn off lazy writing. The RFC said there would be, but there's not.
> With that said, the RFC (well, the code in its PR) does introduce a > supplemental
> interface "SessionUpdateTimestampHandler" which adds a > method
> "updateTimestamp" that would be called during lazy writing > instead of write().
That's also fine, but was not implemented. As the RFC was implemented, there is no way to turn
off the lazy write functionality.
If there was ANY way to turn off this functionality (besides rebuilding PHP without the mentioned
comment, which is what GS is doing now), then this wouldn't be an issue at all. Because of
that, I'd consider this to be a bug. The RFC was fine in that it introduced multiple
workarounds but that was not implemented, which is why it is breaking applications.
------------------------------------------------------------------------
[2014-11-04 14:55:15] denis at slik dot eu
This is a backwards incompatible change.
For reasons very similar to the original submitter, this has broken our application.
Strongly consider updating your migration notes as well as the original documentation:
http://php.net/manual/en/migration56.incompatible.php
http://lt1.php.net/manual/en/function.session-set-save-handler.php
------------------------------------------------------------------------
[2014-11-01 01:31:05] requinix@php.net
Then you should definitely raise the issue on the internals list. I've read through a lot of
emails about this but I'm still not certain why the RFC's code is pending - they might be
able to resolve it, or at least explain what its current state is.
------------------------------------------------------------------------
[2014-11-01 00:57:46] jay at grooveshark dot com
Fellow Grooveshark developer here. Our session handler adds some OOP functionality, the reasons for
which are outside the scope of this discussion, but the reason this change causes problems for us is
that PHP does not always know when the session data has changed, because some of our session data is
not part of $_SESSION. Our custom save handler already checks to see if a write is actually
necessary, so this optimization not only causes this bug for us where write is not being called when
we expect it to be, but it also doesn't optimize anything for us. If this functionality was
behind a flag we could easily turn it off, but for now we are having to choose between rewriting the
way our session handler works or recompiling PHP without the code in that commit.
------------------------------------------------------------------------
[2014-10-31 20:03:32] requinix@php.net
> what is the point of having an RFC if the results are ignored by resolving a
> feature request bug with a finite feature from the RFC?
The RFC is not being ignored. Might be out of the spotlight at the moment but as far as I know
there's still every intention on it being implemented.
Besides, as you saw the change happened before the RFC.
> The feature request didn't even ask for what was implemented
It suggested a flag, but the core issue was that sessions were being rewritten unnecessarily and
that PHP should check for changes so that the write could be skipped. @yohgaki implemented exactly
that.
> which for some reason is still assigned to PHP 4.2.1 in the bug tracker
The field is for what version the bug is being filed against, not when it is fixed.
> The documentation does not state that storage handlers won't be called in
> some cases.
True, and I agree that it would be a good thing to mention.
> This results in custom session implementations having to do the writing in
> close() with a bunch of convoluted logic to get the serialized session data
> from read() or write().
If you want to make write() rewrite the session regardless of changes, apparently? The point is that
you don't have to do that.
The RFC reintroduces the idea of lazy writing as an optional feature so when that is in then
you'll be able to (not) use it.
> The inability to have the timestamp updated via write() on a custom session
> is a bug in my opinion. This would be fine if there were something like
> updateTimestamp as an alternative.
Personally I prefer this lazy writing. write() can update a modification timestamp, open() or
close() can update an access timestamp, and you GC based on access time.
With that said, the RFC (well, the code in its PR) does introduce a supplemental interface
"SessionUpdateTimestampHandler" which adds a method "updateTimestamp" that would
be called during lazy writing instead of write(). So that should address your concerns.
Putting aside your (very understandable) confusion regarding the lazy writing change and the RFC, I
NABed this because the change was made intentionally as a resolution to an old feature request. Now
that you've explained that it's not just a matter of an unexpected change but that it
causes a problem for you, though it still seems an avoidable one to me, I'd reconsider.
However the RFC still resolves that. I'm not entirely sure of its status, but like I said I
think it's still intended to be merged in at some point. There might have been an outstanding
issue preventing it from being merged into 5.6? If you're not averse to mailing lists then I
suggest asking on internals to find out for sure what's happened to it.
http://php.net/mailing-lists.php
------------------------------------------------------------------------
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
https://bugs.php.net/bug.php?id=68331
--
Edit this bug report at https://bugs.php.net/bug.php?id=68331&edit=1