Version imprimable
Bonjour,
Est-il possible, dans une procédure stockée de poser explicitement un verrou sur certaines lignes d'une table de sorte que les autres sessions ne voient pas, par un select, les lignes sur lesquelles le verrou est posé.
Merci pour vos réponses
Bonjour,
Oui, select for updateCitation:
poser explicitement un verrou sur certaines lignes d'une table
Non, un verrou n'empêche pas de voir.Citation:
de sorte que les autres sessions ne voient pas
Cordialement,
Franck.
c'est bien ce qui me semblait. J'en ai maintenant la confirmation.
Merci pour la réponse
R83
Sauf, lorsque le verrou concerne l'ordre DELETE.Citation:
Non, un verrou n'empêche pas de voir
Une méthode pour y arriver serait de supprimer les lignes concernées le temps de la transaction, puis dans une transaction autonome procéder au traitement proprement dit, et en final faire un ROLLBACK.
Pendant ce temps là, les sessions concurrentes ne verront pas les lignes car l'ordre SELECT émis tiendra compte des suppressions contenues dans les redo logs en ligne (me semble-t-il !)
:ccool:
.
Bonjour star,
Dans ton exemple (delete+rollback) une session concurrent verra ses enregistrements: lorsqu'il ira les lire, il sera en attente de verrou puis le rollback qui relachera le verrou et alors les liges seront là.
Et désolé, mais les redo logs n'ont rien à voir là dedans :?
cordialement,
Franck.
Non, c'est complétement erroné.Citation:
Envoyé par star
Lisez Multiversion Read Consistency et Overview of Autonomous Transactions
Alternativement essayez de prouver avec un exemple vos propos.
je confirme le point de vue de "pachot" avec un select for update, tu vérouille toute la table pour insert ou delete, mais tu peux jamais vérouiller un select sur table quelque soit le motif.
Dans la conception même de la notion de transaction, cette ineptie est regrettable de la part du SGBD Oracle. La lecture de données à l'instant T devrait tenir compte des modifications en cours des données transactionnelles, à mon sens !
Admettons d'un moment donné, qu'une transaction débite un compte pour en créditer un autre, comment alors empêcher une autre de faire la même transaction alors que le compte est à zéro avant consolidation. Oui, la notion de transaction doit se situer au plus près de l'action, càd, au moment même de l'intention de l'utilisateur (de l'interaction via l'IHM).
Cas d'école. La règle voudrait qu'un verrou soit avant tout posé sur l'objet mais bon ce n'est pas forcément la solution.
:roll:
.
Star,
C'est le but du select for update: tu veut garantir que les données que tu lis ne changent pas durant toute ta transaction.Citation:
Admettons d'un moment donné, qu'une transaction débite un compte pour en créditer un autre, comment alors empêcher une autre de faire la même transaction alors que le compte est à zéro avant consolidation
Un select simple (sans le 'for update') lis des données consistantes, conformément au niveau d'isolation.
Etudie le concept de transaction et d'isolation, puis sur le fonctionnement d'Oracle. Je ne suis pas sûr que tu maîtrise assez l'un et l'autre pour porter ce genre de jugement.Citation:
Dans la conception même de la notion de transaction, cette ineptie est regrettable de la part du SGBD Oracle.
Cordialement,
Franck.