le principe du lock fichier est un principe de lock atomique dans le cadre d'absence de gestion de la copie d'edition.
tu fais la meme chose sur un CVS avec "edit" et "unedit". une maniere de gerer cela sur un SGBD vient à n'avoir qu'une transaction effective sur un element ( base, table, tuple, attribut ), et de faire une copie de l'element concerné pour le remplacer au COMMIT. le Copy On Write permet d'aleger le systeme et de le rendre plus veloce.
Par contre avec la notion de copie des transactions, cela evite d'avoir un readlock sur l'element en cours de transaction et donc de garantir l'integrite et l'atomicite du commit. avec un readolck le commit n'est plus atomique mais devient element transactionnel qui doit etre annulé en cas de readlock. ce qui fait dans le cas de SQLite, le code erreur retourné pour rejouer plus tard la transaction.
conclusion dans un systeme critique à lecture forte, le commit n'est pas priorisé et peut en cascade, perturber l'integrité globale d'un systeme.
[^] # Re: revenons sur terre
Posté par Mouns . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 4.
tu fais la meme chose sur un CVS avec "edit" et "unedit". une maniere de gerer cela sur un SGBD vient à n'avoir qu'une transaction effective sur un element ( base, table, tuple, attribut ), et de faire une copie de l'element concerné pour le remplacer au COMMIT. le Copy On Write permet d'aleger le systeme et de le rendre plus veloce.
Par contre avec la notion de copie des transactions, cela evite d'avoir un readlock sur l'element en cours de transaction et donc de garantir l'integrite et l'atomicite du commit. avec un readolck le commit n'est plus atomique mais devient element transactionnel qui doit etre annulé en cas de readlock. ce qui fait dans le cas de SQLite, le code erreur retourné pour rejouer plus tard la transaction.
conclusion dans un systeme critique à lecture forte, le commit n'est pas priorisé et peut en cascade, perturber l'integrité globale d'un systeme.