Discussion :

[r83]

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

[pachot]

Bonjour,

poser explicitement un verrou sur certaines lignes d'une table

Oui, select for update

de sorte que les autres sessions ne voient pas

Non, un verrou n'empêche pas de voir.
Cordialement,
Franck.

[r83]

c'est bien ce qui me semblait. J'en ai maintenant la confirmation.
Merci pour la réponse
R83

[star]

Non, un verrou n'empêche pas de voir

Sauf, lorsque le verrou concerne l'ordre DELETE.
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 !)

.

[pachot]

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.

[mnitu]

Sauf, lorsque le verrou concerne l'ordre DELETE.
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 !)

.

Non, c'est complétement erroné.
Lisez Multiversion Read Consistency et Overview of Autonomous Transactions

Alternativement essayez de prouver avec un exemple vos propos.

[mongilotti]

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.

[star]

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.

.

[pachot]

Star,

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

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.

Un select simple (sans le 'for update') lis des données consistantes, conformément au niveau d'isolation.

Dans la conception même de la notion de transaction, cette ineptie est regrettable de la part du SGBD Oracle.

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.

Cordialement,
Franck.