CFLock indispensable aux variables de session ?

Résolu
donatejj Messages postés 3 Date d'inscription samedi 14 octobre 2000 Statut Membre Dernière intervention 28 août 2006 - 24 août 2006 à 16:03
lmougin Messages postés 7 Date d'inscription vendredi 1 octobre 2004 Statut Membre Dernière intervention 13 février 2007 - 13 févr. 2007 à 22:45
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

syndrael Messages postés 2378 Date d'inscription lundi 4 février 2002 Statut Membre Dernière intervention 29 décembre 2012 19
24 août 2006 à 17:11
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.
3
nickadele Messages postés 1251 Date d'inscription mercredi 7 août 2002 Statut Modérateur Dernière intervention 10 avril 2013
26 août 2006 à 14:35
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
3
syndrael Messages postés 2378 Date d'inscription lundi 4 février 2002 Statut Membre Dernière intervention 29 décembre 2012 19
26 août 2006 à 19:13
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.
3
nickadele Messages postés 1251 Date d'inscription mercredi 7 août 2002 Statut Modérateur Dernière intervention 10 avril 2013
27 août 2006 à 13:55
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
3

Vous n’avez pas trouvé la réponse que vous recherchez ?

Posez votre question
syndrael Messages postés 2378 Date d'inscription lundi 4 février 2002 Statut Membre Dernière intervention 29 décembre 2012 19
27 août 2006 à 15:14
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.
3
donatejj Messages postés 3 Date d'inscription samedi 14 octobre 2000 Statut Membre Dernière intervention 28 août 2006
25 août 2006 à 10:29
Merci pour cette réponse.   Pas d'autre avis ?
0
donatejj Messages postés 3 Date d'inscription samedi 14 octobre 2000 Statut Membre Dernière intervention 28 août 2006
28 août 2006 à 10:26
Merci pour vous réponses qui ont bien clarifié pour moi la problèmatique des variables de session et du Lock.
0
lmougin Messages postés 7 Date d'inscription vendredi 1 octobre 2004 Statut Membre Dernière intervention 13 février 2007
13 févr. 2007 à 22:45
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 !
0
Rejoignez-nous