CFLock indispensable aux variables de session ?

Réponse acceptée !
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.

Réponse acceptée !

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

Réponse acceptée !
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.

Réponse acceptée !
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

Réponse acceptée !
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.