Version imprimable
Bonjour à tous et merci à la communauté pour son implication.
Le code est fais de la sorte :le souci est que, il arrive qu'un autre process fasse un lock juste après le premier "COMMIT;" du coup le "select for update nowait;" échoue et la suite des traitements n'a pas lieu !Code:
2
3
4
5
Est-il est possible de faire le COMMIT, mais sans délocker la ressource ?
1000 merci
D'après les informations fournies il suffit de ne pas faire le premier commit.
Oui, seulement ce n'est pas possible !
il s'agit de briques indépendantes et complémentaires et dont l'appel n'est pas toujours dans le même ordre.
Les briques n'ont pas à commit leur traitement, c'est au code qui assemble les briques de faire le travail de validation de la transaction, car lui seul a la vision de la transaction dans son ensemble.
Entièrement d'accord. Sauf que c'est historique !
c'est un projet qui a plus de 15 ans d'age, équipe d'une dizaine de personne.
personne ne maitrise vraiment tout, et l'étude d'impact (pour virer le premier commit) sera très couteuse, voir impossible à réaliser.
le plus important pour moi c'est de savoir s'il y a une façon pour parer le problème, ou le contourner ? si vous avez des suggestions je suis preneur.
Merci beaucoup
Non.Citation:
Est-il est possible de faire le COMMIT, mais sans délocker la ressource ?
Des solutions existent toujours mais, ...Citation:
Envoyé par cyclone_yas
1° Traitement en base mono-utilisateur
2° Modifiez le code pour qu'il ne fasse pas le commit dans certaines conditions
3° Supprimez le nowait
4° Modifiez le code pour qu'il ré-essaie de verrouiller plus tard les enregistrements
...
Merci bien mnitu
Est ce que tu peux expliciter ta solution de contournement ?
Laquelle ?Citation:
Envoyé par cyclone_yas