:::: MENU ::::

Unserialize web2py requests and allow concurrent accessDésérialiser des requêtes web2py et permettre des accès concurrents

  • Mar 14 / 2014
  • 0
Python, web2py

Unserialize web2py requests and allow concurrent accessDésérialiser des requêtes web2py et permettre des accès concurrents

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).Avec une configuration par défaut de votre application Web2py, vous pourrez noter que lorsque vous lancez une action, si celle-ci prend un peu de temps à s’exécuter, vous ne pouvez pas ouvrir un nouvel onglet de votre navigateur pour exécuter une autre requête sur la même application. Ceci est dû au fait que lorsque vous exécutez une action, votre navigateur transmet vos informations de session au serveur et votre fichier de session côté serveur est donc ouvert en écriture pour être mis à jour. Un verrou est donc mis en place sur le fichier, empêchant toute autre action de démarrer tant que le verrou n’est pas lâché.

Ce problème ne se présente donc effectivement pas si vous utilisez un système de gestion des sessions sur une base de données et non sur un système de fichiers. Pour utiliser un système de bases de données, il vous faut pour une base de données déclarée :

initier la connexion sur cette base pour les sessions :

Une table va alors être automatiquement créée, sera appelée web2py_session_appname et contiendra les champs suivants :

Si vous souhaitez utiliser le système de fichiers de session, il vous faudra alors utiliser la commande suivante pour permettre de libérer ce fichier de session :

Notez bien que cette commande ne doit être appelée que si l’action exécutée ne nécessite pas d’informations de session. Par exemple, si vous chargez du contenu dynamiquement via des appels Ajax à différents endroits de la page vous pouvez ajouter cette commande pour chaque appel afin de permettre leur exécution concurrentielle sachant que les informations de connexion sont enregistrées sur le chargement de la page principale.

Pour tester, vous pouvez utiliser le code suivant :

Si vous appelez le code précédent en enlevant la commande session.forget() vous obtiendrez le résultat suivant :

Si vous appelez le même code en laissant la commande session.forget() vous obtiendrez alors :

On constate donc bien qu’entre les deux cas, nous avons une exécution concurrentielle fonctionnelle grâce à la fonction session.forget() et que la durée d’exécution de la page peut, de fait, être fortement optimisée.

Notez bien que la plupart des navigateurs ne permettra pas d’exécuter plus de 6 requêtes en même temps, d’où le résultat du dernier test où l’on constate que les 6 premières requêtes sont exécutées ensemble alors que les suivantes sont exécutées ensuite (sur un deuxième flot mais également en concurrence).

Leave a comment

You must be logged in to post a comment.

Question ? Contact