AJAX-ready sessions about zendframework

[zfbot]

This issue was ported from the ZF2 Jira Issue Tracker at
http://framework.zend.com/issues/browse/ZF2-141

Known GitHub users mentioned in the original message or comment:
@ralphschindler

[mwillbanks]

@weierophinney would like to know what you recommend here; IMO locking could lead to naughty behavior. Since the last request in PHP sessions ALWAYS wins.

If we locked the session we would have to wait until the lock was released thus cycling in a looping pattern on the session open until the lock is released and all SaveHandlers would need to provide a method to:

1. Check if a lock exists
2. Lock
3. Unlock

Additionally; we would need to guarantee that the session would be unlocked by the request even if it encountered a fatal error (i believe this is impossible because I don't believe shutdown commands get called in the case of a fatal php error), lock timeouts and all of that. The negative harm by doing something like this is massive and might be better left to the end user overwriting the save handler to provide this type of functionality in the event that they really understand the consequences.

The only other way around this is to re-read the session at the end of the request by:

1. Retaining state changes in the current session
   a) Take a crc32 of the current session
   b) Storage must retain notes about each data point if it was new, changed or removed
   b) At the end of the request compare crc32 of original vs. re-read session
   c) If not matching; compare original at open time against current:
   - New keys
   - Changes in keys
   - Removal of keys
   d) Apply delta of changes from the session

IMO this is an extremely complex workflow that hits an edge case that we do not need to solve; it provides negative impact to performance and creates an overall complexity that would be no fun :)

[ralphschindler]

Agreed, I'm all for closing this. Also, the original reporter never came back to this issue.

[ThaDafinser]

Reference #4585

[yaronel]

I don't understand why you closed this issue.
This has been a nagging problem for years now.
It may be hard to reproduce, but it's not an edge case. Making multiple ajax calls at a time is a common things.
Any chance you'll revisit this bug?

Thanks.

[ThaDafinser]

@yaronel if you have parallel ajax calls you need todo read only sessions.

Otherwise you will always have problems (since some ajax calls can take longer and overwrite again and so on...)

[mwillbanks]

@yaronel please see my comments on the top portion of the request, there are ways to accomplish this but very complex.

[ziadloo]

Hi,

This is the original reporter of this issue. I know this is an old/closed ticket but I just wanted to clear somethings up things because it could be useful to someone else. But before that, the reason I never followed up on this is that I never saw this thread here. I had opened this ticket in ZF forum (I think) and it was moved here and I guess I missed it.

Anyways, answering the @mwillbanks from 2013:

I think you are going the wrong way. The type of locking that I was thinking of is to delegate it to some external process. Like OS or the database engine. You don't need to implement the locking mechanism in PHP. For instance, flock can be used if the session data is stored in files. Or for MySQL if the engine is InnoDb you could use SELECT ... FOR UPDATE. Nevertheless, it will be a blocking lock. Meaning, once you ask for a session data that it is locked by some other process, your function call will halt and your process is blocked till the lock is lifted or your process is timed out. In cases like you've mentioned (fatal PHP errors) the responsibility of handling the locks will be by the external software and I know that they handle it pretty well. It's also worth mentioning that the blocked processes will form a queue (or at least they are supposed to and I'm not sure if the external software are implementing that or not).

It's been years since I worked with PHP and/or ZF so I cannot say this with confidence but I believe at some point the locks were implemented for session data. But as far as I remember, there was only one type of access (read & write) and you could not read the session without acquiring a lock. I remember that ZF was locking the session and only there could be one requests per session executed at a time (this was later after I had created this ticket). I had implemented my own version of this but at this point, I don't know if I have access to my code or not.

In the end, I strongly believe that such two accesses (read-only and read&write) could improve the performance of a service-oriented backend since not all requests try to write to the session and those should not be blocked by other requests.