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
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
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
20
24 août 2006 à 17:11
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.
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.
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
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
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
syndrael
Messages postés
2378
Date d'inscription
lundi 4 février 2002
Statut
Membre
Dernière intervention
29 décembre 2012
20
26 août 2006 à 19:13
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.
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.
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
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
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
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
20
27 août 2006 à 15:14
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.
J'aime limiter à un écran la navigation.. et puis avec la folie Web2.0
je vois ke j'avais po foncièrement tort..
S.
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
25 août 2006 à 10:29
Merci pour cette réponse. Pas d'autre avis ?
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
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.
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
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 !
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 !
