[Servlet] concurrence d'accès aux fichiers dans une servlet

Bonjour,
la problematique a laquelle je me trouve confrontee me semble classique. Il doit donc surement exister un pattern standard pour l'implem. Or je ne le connais pas et comme je ne voudrais pas re-inventer la roue...svp, eclairez-moi!

problematique:
mon appli web permet aux utilisateurs d'editer un ensemble de fichiers (stocker sur le serveur) commun a tous les utilisateurs. Il y a donc un probleme de concurrence d'acces a gerer pour eviter que deux (ou plus) utilisateurs se retrouvent entrain de travailler sur le meme fichier en meme temps.
Chaque edition, par un utilisateur, se traduit par plusieurs appels successifs a ma servlet.


plus en detail:
je voudrais donc, lorsqu'un utilisateur fait une requete a ma servlet, proceder comme suit:
1. la servlet verifie si le fichier est deja editer par qq'un d'autre (c-a-d une autre session que la sessuin courante),
2. si non, la servlet prend un "lock" sur le fichier en lui associant la session courante (pour pouvoir savoir qui est entrain d'editer),
3. la servlet effectue plusieurs actions de lecture et ecriture sur le fichier en question (via plusieurs FileWriter et FileReader et XSL transformations),
4. la servlet renvoie une reponse,
5. le meme utilisateur envoie une nouvelle requete (suite de l'edition sur le meme fichier toujours),
6. la servlet verifie si le fichier n'est pas entrain d'etre editer par quelqu'un d'autre (non puisque c'est cette session, dans notre exemple, qui edite le fichier),
7. la servlet effectue encore d'autres actions de lecture et ecriture sur le fichier puis, determine que c'est la fin de l'edition et libere le "lock" posee sur le fichier par cette session, lors d'une requete precedente. le fichier sera alors disponible lors d'une requet a la sevlet effectuee par une autre session.

voila. desolee d'avoir ete un peu prolixe...
Merci!
Pi2.



[Modéré par Didier] : ajout de tag dans le titre - Les règles du forum Java

Un pattern existant, je ne vois pas !
Mais je peux te dire ce que je ferais concrètement dans le même cas. On sait jamais, ça peut te convenir !

Je stocke l'identifiant de session (et éventuellement des infos complémentaires : date, heure, nom, ...) de l'utilisateur qui est en train d'éditer un fichier. On peut stocker dans un fichier text ou en base de données, peut importe. Je confie ce stockage d'information à une méthode synchronized d'un objet dédié, ceci afin d'éviter les écritures concurrentes de verrou.

A chaque demande d'édition d'un fichier, je vérifie donc s'il n'existe pas de verrou sur ce fichier. S'il en existe un, j'affiche un super message du genre "Impossible : <nom> édite le fichier <fichier> depuis <date> <heure>". S'il n'en existe pas, alors roulez jeunesse : j'inscris le verrou à l'aide de ma méthode synchronized et je permets l'édition.

A chaque action d'édition, on met à jour la date et l'heure d'édition du verrou.

Quand l'utilisateur termine son édition, on supprime le verrou toujours à l'aide d'une méthode synchronized.

Après reste un problème à gérer : le cas où un utilisateur demande l'édition d'un fichier, l'obtient et laisse expirer sa session sans terminer son édition. On se retrouve alors avec un fichier bloqué puisqu'un verrou est inscrit et qu'il ne peut plus être enlevé. Pour moi, il suffit de comparer la date et l'heure du verrou avec la date et l'heure courantes. Si le délai est supérieur au délai d'expiration d'une session, on ne tient plus compte du verrou inscrit sur le fichier et on le supprime.

Merci. C'est en fait, ce que j'avais pense et que j'ai finalement implemente hier apres-midi (apres avoir pose ma question). La seule difference est pour la gestion du cas ou la personne a pris un "verrou" sur un fichier et que sa session expire sans qu'elle est rendue le verrou.
Pour pallier a cela, je stocke chaque "verrou", posé sur un fichier, dans la session de l'utilisateur qui pose le verrou. De plus, j'ai implemente un SessionListener qui, lorsqu'une session est detruite, parcourt tous les attributs de la session et, lorsqu'il tombe sur un verrou, le libere. Et paf! le tour est joue. Ca m'evite d'avoir a comparer les date/heure et puis ca rappelle un peu la programmation par Aspect...Or, il me semble que la concurrence est typiquement un aspect dans mon cas. :-)
En tous cas, merci de m'avoir confortee dans mon idee!
Pi2.