Discussion :

[stbeau1112]

Bonjour à tous,

Après avoir parcouru énormément de sujet concernant les transactions, je suis dans le flou concernant le type de niveau d’isolement que je dois mettre en œuvre pour mon application en cours.

Je développe actuellement une application de gestion sortie de palette d’un magasin industrielle.

Dans le principe, des utilisateurs programme depuis des applications clientes une liste de palettes devant être chargées dans un camion qui se présentera sur un quai. Quand une liste est enregistrée, tous les palettes la constituant se voit attribué le tag « Réservée » et n’est donc plus disponible. Et c’est sur ce point que je m’interroge concernant les accès concurrentiels.


Application Cliente :
1 - Création de la liste de palettes => Uniquement celle non « Réservé »
2 - Une fois la liste complète, enregistrement dans la BD en déclarant toutes les palettes contenues comme « Réservé ».


Procedure Stockée d’enregistrement
1 - Vérification que les palettes soit toujours disponible
(Bien évidemment pendant qu’un utilisateur prépare ca liste, un autre peu en enregistrer une contenant des palettes communes d’où cette vérification)
2 - Traitement Divers

3 - Réservation définitive des palettes


Voilà ou se situe mon doute, je pense que je dois mettre en place un système de verrouillage pour qu’une fois la vérification faite, personne ne puisse enregistrer une liste.

D’après toutes les lectures que j’ai faites au sujet du niveau d’isolement, j’étais parti sur la plus bloquante : SERIALIZABLE

Vos Avis ?

Voilà j’espère avoir été assez clair et vous remercie d’avance de votre participation.

[SQLpro]

S'il n'y a pas d'insertion perturbante (par exemple sommation d'un groupe de ligne) alors le REPEATABLE READ suffit.

Attention, ne pas oublier :
1) de gérer une transaction
2) de revenir en READ COMMITTED en fin de transaction.

PS : on ne parle pas de niveau d'isolement mais de niveau d'isolation !

A +

[stbeau1112]

Merci bien