Transactions, quand devrait être jeté et annulé

Question

J'essaie de déboguer une application (sous PostgreSQL) et je suis tombé sur l'erreur suivante: "La transaction en cours est abandonnée, les commandes sont ignorées".

Autant que je sache, une "transaction" est juste une notion liée à la connexion à la base de données sous-jacente.

Si la connexion a une validation automatique "false", vous pouvez exécuter des requêtes via la même instruction tant qu'elle n'échoue pas. Dans ce cas, vous devriez revenir en arrière.

Si la validation automatique est " true " cela n'a pas d'importance tant que toutes vos requêtes sont considérées comme atomiques.

En utilisant auto commit false, j'obtiens l'erreur mentionnée ci-dessus par PostgreSQL, même lorsqu'un simple

select * from foo

échoue, ce qui me fait demander sous quelle (s) exception (s) SQLE est une "transaction" considéré comme non valide et doit être restauré ou non utilisé pour une autre requête?

  

utilisant MacOS 10.5, Java 1.5.0_16, PostgreSQL 8.3 avec le pilote JDBC 8.1-407.jdbc3

Answer 1

Cette erreur signifie qu’une des requêtes envoyées dans une transaction a échoué. Le reste des requêtes est donc ignoré jusqu’à la fin de la transaction en cours (ce qui sera automatiquement une annulation). Pour PostgreSQL, la transaction a échoué et sera annulée dans tous les cas après l'erreur avec une exception. Vous devez prendre les mesures appropriées, l’un des

1. ignore la déclaration et recommencez une nouvelle fois.
2. utiliser des SAVEPOINT pour la transaction pour revenir à ce moment et essayer un autre chemin. (Ceci est l'exception)

Activez la journalisation de la requête pour voir quelle requête est la requête en échec. et pourquoi.

Dans tous les cas, la réponse exacte à votre question est que toute exception SQLException doit signifier qu'une annulation est survenue lors de l'envoi de la commande de fin de transaction, c'est-à-dire lorsqu'un COMMIT ou un ROLLBACK (ou une FIN) est émis. Voici comment cela fonctionne: si vous utilisez des points de sauvegarde, vous serez toujours lié par les mêmes règles. Vous pourrez simplement revenir à l'emplacement où vous avez enregistré et essayer autre chose.

Answer 2

Cela semble être un comportement caractéristique de PostgreSQL qui n'est pas partagé par la plupart des autres SGBD. En général (en dehors de PostgreSQL), vous pouvez faire échouer une opération à cause d'une erreur puis, dans la même transaction, essayer d'autres actions qui aboutiront, compensant ainsi l'erreur. Un exemple: considérons une opération de fusion (insertion / mise à jour). Si vous essayez d'insérer le nouvel enregistrement mais trouvez qu'il existe déjà, vous pouvez passer à une opération UPDATE modifiant à la place l'enregistrement existant. Cela fonctionne bien dans tous les principaux SGBD. Je ne suis pas certain que cela ne fonctionne pas dans PostgreSQL, mais les descriptions que j'ai vues ailleurs, ainsi que dans cette question, suggèrent que lorsque la tentative INSERT signifie que toute activité ultérieure dans la transaction est vouée à l'échec. Ce qui est au mieux draconien et au pire "inutilisable".