Discussion :

[StringBuilder]

Bonjour,

J'ai un client qui me pose un problème de "verrouillage" de lignes dans une base.

Pour faire simple :

Quand un utilisateur charge des lignes à l'écran, il faudrait que ces lignes ne soient pas visibles pour les autres.

J'ai pensé faire une usine à gaz genre :

onload = ajax qui va flagger dans la base chaque ligne affichée à l'écran
onunload = ajax qui va déflagger dans la base chaque ligne affichée

Le souci, c'est que se passe-t-il si le script "onunload" met 3 plombes à s'exécuter ? il s'interrompt de lui-même ? bloque le navigateur ? tourne en tâche de fond ?

Plus tous les cas tordus où l'utilisateur va planter et/ou fermer sauvagement son navigateur, ou perdre la connexion internet...

Bonne pratique ou pas ?

Sinon, j'ai une autre idée, peut-être encore pire :
- onload puis toutes les 60 secondes : mettre à jour les lignes visibles à l'écran avec l'heure actuelle + utilisateur connecté
- au chargement, vérifier qu'aucune ligne n'a été flaggée avec un autre utilisateur depuis moins de 60 secondes.

J'me fait peur des fois pour imaginer des trucs pareils...

De meilleures idées ?

[sekaijin]

pas d'ajax sur unload

Ajax est un appel asynchrone donc le traitement à de très forte chance d'être interrompu vu que un load va le déclencher et quitter la page sans attendre.

le seul moyen efficace de traiter ce genre de chose et de le faire côté serveur avec un timeout

lorsque l'utilisateur quitte la page il est renvoyé vers un page qui libère les ressources
si l'utilisateur ne quitte pas proprement le timeout est là pour libérer les ressources

si l'utilisateur reste inactif trop longtemps et qui agit sur les donnée alors que côté serveur les donné ont été libéré il faut interrompre le traitement lui signaler que le timeout est dépassé et lui proposer de charger les nouvelles données si elle sont disponibles.

mais plutôt que de réserver (locker) les données, en général on les dates. ainsi lorsque l'utilisateur les demande on garde la date de la demande dans l'espace de l'utilisateur.
au moment de les traiter on vérifie que la date des données est inférieure à la date de demande de l'utilisateur.
si c'est le cas on peut les traiter sinon cela signifie qu'un autre utilisateur les a modifiés
dans ce cas on propose à l'utilisateur d'utiliser la dernière version.

Ainsi il n'y a pas de donnée réservées mais uniquement des données partagées.

A+JYT

[thelvin]

Ajax est un appel asynchrone donc le traitement à de très forte chance d'être interrompu vu que un load va le déclencher et quitter la page sans attendre.

On peut tout à fait faire de l'ajax synchrone... On a qu'à appeler ça du bjax pour "blocking" s'il y en a qui aiment pas l'oxymore "ajax synchrone."
Par contre, bien que mes navigateurs acceptent d'honorer ce genre d'appel même dans des contraintes assez rudes, je n'espérerais pas trop que ça marche tout le temps. Genre à une époque unload avait le droit d'ouvrir des pop-ups et maintenant ce n'est plus le cas : on fait pas attendre l'utilisateur qui a décidé de partir. Vraisemblablement si le site ne répond pas assez vite à la requête synchrone, le navigateur ne devrais pas l'attendre longtemps avant de s'en aller sans l'honorer.

Et il reste tous les cas où l'event ne peut pas être traité ou n'existe pas (cas nettement plus probable du gars qui a oublié qu'il a un onglet ouvert sur ces lignes.)