:::: MENU ::::

Unserialize web2py requests and allow concurrent access

  • Mar 14 / 2014
  • 0
Python, web2py

Unserialize web2py requests and allow concurrent access

With a default configuration for your web2py application, you will notice that when you are launching an action, if this one is quite long to execute, you won’t be able to open a new tab to run another request on the same application. This can be explained because when you are launching an action, your browser is sending session informations to the server and your session file on server-side is so opened in writing mode for being updated. A lock is set on this file, blocking any other action to be executed for this session while the lock is not released.

This problem is effectively not existing if you are using a database for your session management instead of a file system. To use a database system, you just need to declare your database:

and initiate the connection to this database for sessions:

A table will so be automatically created, named web2py_session_appname and will contain following fields:

If you want to use the file system for your sessions, you will need to use the following command to allow the session file release:

You will notice that this command must only be called if the action you want to execute do not require to session informations. For example, if you are loading dynamically some contents via Ajax calls on several parts of the page, you can add this command for each call to allow the concurrential execution knowing that the connection informations are saved while main page is loading.

As testing, you can use following code:

If you’re calling previous code by deleting the session.forget() command call, you will get this as a result:

If you’re calling the same code with the session.forget() command call, you will get:

We can notice that between both cases, we have a concurrential execution thanks to the session.forget() function, and that we can hardly optimize the page loading time.

Please note that most of browsers won’t allow you to execute more than 6 requests at the same time, hence the result we are getting with the last test where we can see that the six first requests are executed together whereas the following ones are executed afterwards (on a second flow but concurrent also).

Leave a comment

You must be logged in to post a comment.

Question ? Contact