CFLock indispensable aux variables de session ?

Résolu
Messages postés
3
Date d'inscription
samedi 14 octobre 2000
Statut
Membre
Dernière intervention
28 août 2006
-
Messages postés
7
Date d'inscription
vendredi 1 octobre 2004
Statut
Membre
Dernière intervention
13 février 2007
-
Bonjour à tou(te)s,

Est-il indispensable de "locker" l'écriture et la lecture des variables de session dans un site en intranet et quels sont les risques concrets si on ne le fait pas ?

Contexte :

      * CF 5 sur Windows 2000 server avec IIS 5
      * environ 50 utilisateurs concurentiels

D'avance merci,

Jean-Jacques.

8 réponses

Messages postés
2378
Date d'inscription
lundi 4 février 2002
Statut
Membre
Dernière intervention
29 décembre 2012
19
Bonjour,

Perso je lock mes variables d'application, mais de session je ne vois
pas l'interêt puisque ce sont des données que tu ne partages avec
personne.

S.
Messages postés
1251
Date d'inscription
mercredi 7 août 2002
Statut
Modérateur
Dernière intervention
10 avril 2013

Pourquoi faire un lock ?


En fait ce processus est utilisé si on souhaite éviter que 'n' traitements modifient la valeur d'une variable, donc lorsqu'un second (ou n) traitement (trhead) vient se présenter pour modifier la variable, il devra attendre que le traitement précédent ai terminé avant de pouvoir faire toute action.


Dans ton cas il s'agit d'un intranet donc le risque est faible qu'un petit malin essaye de foutre le b..... !
Mais pour une bonne programmation il est mieux d'utiliser ce mécanisme!


Ceci ne se limite pas aux variables d'application ou de session, en fait la notion de server, d'application ou de session définit le niveau d'attente du traitement c'est à dire le scope !
<cflock scope="server" ... : mettra en attente toutes demandes peu importe l'application ou l'utilisateur !
<cflock scope="application" ... : mettra en attente toutes demandes peu importe l'utilisateur !
<cflock  scope="Session" .... : mettra en attente toutes deamndes émanant d'une même session !

A cela il faut encore différencier une autre notion : le type
readonly ou exclusif : la notion exclusif appliquera le processus tel que décrit ci-dessus tandis que la notion readonly permettra plusieurs traitements (thread), il faut utiliser ce drenier mode uniquement pour l'initialisation de variables dites statique (constante)!

Voilà, en espérant t'avoir éclairé sur la question !

Nickadele
----------------------------------------------
non, ma belle ne s'appel pas Adèle
Messages postés
2378
Date d'inscription
lundi 4 février 2002
Statut
Membre
Dernière intervention
29 décembre 2012
19
Bonjour Nick,

Peux-tu me dire comment on peut être amené à locker les variables de session ?

De mon coté je vois po l'interet, mais tu as peut-être une raison ki m'aurait échappé..

En tout cas ne po locker ses variables d'application est une grave erreur dans le cas d'un site à forte influence..

S.
Messages postés
1251
Date d'inscription
mercredi 7 août 2002
Statut
Modérateur
Dernière intervention
10 avril 2013

Hello syndrael,

il faut savoir qu'une session est lié à une machine et à un browser.
Si tu ouvres la même page avec 2 browser différents, tu obtiendras 2 sessions, par contre si tu ouvres la même page avec 2 fenêtres d'un même browser tu auras 1 session.

Donc imagine que lorsqu'un utilisateur s'identifie (ou autre traitement) sur ton site, tu lui crées une série de variables paramètres (variable objet etc...) lié à sa session avec des transactions sur la DB pour bien faire compliqué .
L'utilisateur pourrais utiliser 2 fenêtres (même session) et lancer en simultaner cette opération. Le deuxième appel pourrait arriver au moment ou le traitement du premier appel n'est pas terminé et ainsi rentrer en conflit avec le premier voir changer des valeurs initiales du premier traitement.

Un exemple vaut mieux que de long discourt :
Un utilisateur s'identifie avec un profil A et un profil B en simultané sur base du scénario décrit ci-dessus (2 fenêtres d'un même browser).
Le profil A étant différent de B, il initie certaines vairables à certaines valeurs, alors que A arrivent en fin de traitement il finalise la création du profil en modifiant certaines valeurs dans la DB sur base des variables initiales, et a ce moment B arrivent en modifiant les valeurs initiées par A !

Nickadele
----------------------------------------------
non, ma belle ne s'appel pas Adèle
Messages postés
2378
Date d'inscription
lundi 4 février 2002
Statut
Membre
Dernière intervention
29 décembre 2012
19
Ah ouais ok.. mais ce n'est po dans mes pratiques de développement..
J'aime limiter à un écran la navigation.. et puis avec la folie Web2.0
je vois ke j'avais po foncièrement tort..

S.
Messages postés
3
Date d'inscription
samedi 14 octobre 2000
Statut
Membre
Dernière intervention
28 août 2006

Merci pour cette réponse.   Pas d'autre avis ?
Messages postés
3
Date d'inscription
samedi 14 octobre 2000
Statut
Membre
Dernière intervention
28 août 2006

Merci pour vous réponses qui ont bien clarifié pour moi la problèmatique des variables de session et du Lock.
Messages postés
7
Date d'inscription
vendredi 1 octobre 2004
Statut
Membre
Dernière intervention
13 février 2007

Excusez, mais j'ai également les mêmes questionnements...
Et ce n'est pas encore bien clair pour moi.

Faut-il vraiment locker les variables (d'applications ou de sessions) si on ne fait que de la consultation de ces variables (et que l'on ne les modifies pas) ?

Question subsidiaire : peut-on juste faire un cflock en ReadOnly en début de page et le cflock à la fin ? ou il faut faire le lock juste avant l'appel à la variable ?

Merci !