PHPsession concurrency and session read/write lock analysis-PHP source code

It is estimated that many programmers will not think about PHPsession concurrency and session read/write locks, because in general, we will not use session for concurrent operations, but sometimes we may also use it, the following is a session concurrency and session read/write lock article for your reference. It is estimated that many programmers will not think about the PHP session concurrency and session read/write locks, because we generally do not use session for concurrent operations, but sometimes we may also use it, the following is a session concurrency and session read/write lock article for your reference.

Script ec (2); script

PHP is a simple programming language, because the authors of PHP are so cool. Today I will talk about all sessions that phper is familiar ).

Note:

1. The sample code stores session data with files and redis respectively.

2./session/setUserFile and/session/setUserRedis set two keys, user_name and user_id, and sleep for 3 s.

3./session/setLoginFile and/session/setLoginRedis set a key for last_time

4. the/session/indexFile and/session/indexRedis templates contain two ajax requests:/session/setUserFile and/session/setUserRedis, which are executed immediately. The/session/setLoginFile and/session/setLoginRedis have a latency of 300 ms, it is used to simulate the same user and modify session data on both pages (requests) at the same time.

Execution Result Representation:

Request:/session/indexfile

First visit:

Second access:

Request:/session/getsessionfile

Array (3) {["user_name"] => string (10) "xudianyang" ["user_id"] => string (3) "123" ["last_time"] => int (1419411695 )}

Conclusion: The execution time of/session/setUserFile is 3.1 s, /session/setLoginFile: the execution time is 2.81 s (if the ajax latency is added, the response time of both requests is 3.1 s)

Request:/session/indexredis

First visit:

Second access:

Request:/session/getsessionredis

Array (2) {["user_name"] => string (10) "xudianyang" ["user_id"] => string (3) "123 "}

Why?

The manual has the following description:

Void session_write_close (void)

End the current session and store session data.

Session data is usually stored after your script terminated without the need to call session_write_close (), but as session data is locked to prevent concurrent writes only one script may operate on a session at any time. when using framesets together with sessions you will experience the frames loading one by one due to this locking. you can reduce the time needed to load all the frames by ending the session as soon as all changes to session variables are done.

That is to say, the session is locked to prevent concurrent write session data. The session data stored in the file provided by php is added with a mutex lock (when session_start (), which explains that the two requests presented above have the same response time. However, when session data is stored in redis, although the second ajax is not blocked, but the session data is not written to redis, we can trace the source code to get the answer.

Php-5.4.14 source code

Save_handler of the default files

Php-5.4.14/ext/session/mod_files.c

Redis save_handler

The redis_session.c in phpredis does not implement the session read/write lock mechanism. How can we explain this? In fact, if we look at the source code of the session, we can explain it. Because after the SESSION starts session_start, the session data will be read to $ _ SESSION (in the extended internal global variable PS (http_session_vars), when PHP_RSHUTDOWN_FUNCTION (session) (request to be released, use php_session_flush (TSRMLS_C) to write session data to the storage media. That is to say, session data is not written to the storage media in real time.

This explains why/session/setLoginRedis does not seem to write last_time into redis when redis saves session data, however, when the/session/setUserRedis request is released (because there is no last_time key in the first session data), all session data must be written to the storage media, this overwrites the value written by the/session/setLoginRedis request. This explains the problem above.

Test code:

Session. php

 
 
  
  
  
 
   
 
    
The Code is as follows:
 
    
 
 
   
 
   
 
    
      set('user_name', 'xudianyang');        $session->set('user_id', '123');        sleep(3);        echo json_encode($_SESSION);        return false;    }    public function setLoginRedisAction()    {        $session = CoreFactory::session();        $session->set('last_time', time());        echo json_encode($_SESSION);        return false;    }    public function indexRedisAction()    {        // Auto Rend View    }    public function getSessionRedisAction()    {        $session = CoreFactory::session();        var_dump($_SESSION);        return false;    }}
Indexfile. phtml
  Test session concurrency lock