Req #68331 [ReO]: Session custom storage callable functions not being called

From: Date: Wed, 05 Nov 2014 21:39:36 +0000
Subject: Req #68331 [ReO]: Session custom storage callable functions not being called
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-188472@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=68331&edit=1 ID: 68331 User updated by: mark at grooveshark dot com Reported by: mark at grooveshark dot com Summary: Session custom storage callable functions not being called Status: Re-Opened 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. Two reasons I brought up on the internals thread: - We would like to update the timestamp of the session. - We have some data that isn't in $_SESSION that needs to be written. We don't use $_SESSION because we need the data to be indexable (not serialized) and didn't want to duplicate the data in two places. > BTW, I was suggesting "update" handler for the RFC introduce this feature, but there > were objection and withdrawned. I'm unaware of the full objection to that idea; however, I think calling the write() custom handlers until an alternative is implemented would suffice to fix this issue. I understand that doing the lazy write call was an optimization for normal sessions but this change can break some custom session implementations. > I may try to add user space "update" again. Based on what was said on the internals thread it sounds like this isn't an option for PHP 5.6. I assume you mean something can be done for 5.7 and for PHP 5.6 the commit will just have to be reverted? Previous Comments: ------------------------------------------------------------------------ [2014-11-05 21:20:16] yohgaki@php.net 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. ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ 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

« previous php.bugs (#188472) next »