Version imprimable
Bonjour,
Je dois creer un compteur de clicks...
En fait, j ai une FAQ avec 10 liens distincts, et je dois compter le nombre de clicks de chaque lien, le probleme est que je ne peux pas inscrire ces donnees dans une BDD, mais il faudrait que je le fasse dans un fichier texte (avec par exemple lien 1 : 15 clicks, lien 2 : 4 clicks...)
Merci de votre aide
:roll:
Ben si tu ne peux pas utiliser de BDD, alors utilise le fichier texte comme tu l'as dit.
C'est pas propre, mais ceci est un autre problème. :D
Oui, je sais que cela n est pas propre...
Le probleme est de savoir commen faire...:oops:
Merci beaucoup, j avais fouille mais pas trouve ce lien...
Si seulement c'était aussi simple :)
Il demeure un problème. Les accès concurrents au fichiers où tu stocke tes compteurs.
En effet, tu es dans un environnement ASP.NET donc par essence, multithread/multiprocessus, et rien ne dit que deux personnes ne vont pas cliquer sur le même lien en même temps (a peu près en meme temps, pour ton serveur).
L'avantage des BDD, c'est que ce genre de considération est automatiquement résolu et règlé par le SGBD. Lorsqu'une ressources est detenue par un process, les autres sont soient autorisés a y toucher sans vergogne (isolation nulle, comme sous mysql) ou au contraire sont "serialisés" (cas par défaut si MSSQL Server/Sybase ASE/Oracle/..., bien configuré, ou règlable en accèdant à la ressource par transaction), et devrons attendre leur tour, elles sont donc "en attente", pendant ce temps elles ne font rien cela dit, elles sont bloquées (très pratique dans ce cas précis)
Ton problème c'est que si un process écrit dans un fichier au moment où tu tente de le lire... le système d'exploitation va directement te dire d'aller voir ailleurs si tu y es, et ... tu va faire quoi ?
L'autre cas, où tu lit pendant qu'un autre essaie d'écrire... ne vaut pas beaucoup mieux cela dit, car il n'y arrivera pas, accès refusé... et continuera a passer ton chemin... et un clic d'oublié...
Et encore plus drôle...
D'abord tu lis le fichier pour déterminer le nombre, puis tu libere ce fichier pour pouvoir y écrire, mais entre le moment où tu l'a lu et écrit et ou tu veux l'écrire un autre (voir plusieurs autres) peut y écrire... et toi ensuite va écraser cette valeur perdant au passage un incrément. Remarque si au lieu d'y écrire il y lit, le résultat est le meme car il va réécrire la meme valeur que toi dans le fichier... => Clic oublié...
Donc cette méthode est bien, mais très loin d'être fiable.
Heureusement si ton serveur est costaud et que ton site n'a pas trop d'activité, il y a peu de chance que ces problèmes de synchronisation interprocessus ce produisent, mais ils peuvent toujours arriver (c'est très genant si tu veux des statistiques très précises d'accès)
J'espère pas trop t'avoir dégoutté des fichiers textes mais bon... c'est bien de faire quelque chose, mais dans ce cas autant le faire en toute connaissance de cause.
Au moins tu aura une idée d'où ils peuvent provenir. (Les conflits inter-process sur des ressources comme les fichiers... sont pénibles à isoler, et règler)
Pour ça le seigneur a inventé le Mutex ;)Citation:
Envoyé par cinemania
oui le mutex c'est bien, mais ca règle que la synchro multi-thread,
mais histoire de tourner en rond...
ca ne marche pas dans le cas de synchro interprocessus. Et puis les IPC c'est pas la joie non plus...
Juste pour ton information, extrait de la MSDN à propos de la classe Mutex :Citation:
Envoyé par cinemania
Une technique de synchronisation qui peut aussi être utilisée pour la synchronisation inter-processus.Citation:
A synchronization primitive that can also be used for interprocess synchronization.
Mais je te rejoints sur le fait que le problème c'est parfois compliqué à gérer.
A merci pour l'info... sur les mutex de .NET :)
Ca va peut etre me servir, sans devoir déployer des trésors d'ingéniosités finallement, temps mieux :)
Oui, oui, merci pour ces precisions, en fait, j etais au courant mais je ne savais pas que c etait si important...
Je vais y reflechir alors, merci