Pourquoi mettre Autocommit à true?
je me suis longtemps demandé pourquoi L'API JDBC fournit un mode autocommit (java.sql.Connection.setAutocommit()). On dirait une nuisance attirante qui attire les gens dans les ennuis. Ma théorie est qu'il a seulement été ajouté à JDBC afin de simplifier la vie pour les fournisseurs qui voulaient créer des outils pour l'édition et L'exécution de SQL en utilisant JDBC. Est-il une autre raison pour activer la validation automatique, ou est-il toujours une erreur?
7 réponses
malheureusement, l'utilisation d'autocommit est spécifique à la base de données (tout comme le comportement de transaction). Je pense que si vous n'avez pas de stratégie globale de transaction programmée, autocommit est probablement mieux que d'espérer que tout le monde ferme/retranche correctement les transactions.
en parlant pour MySQL, vous pouvez laisser autocommit=true on par défaut, et il s'éteindra automatiquement lorsque vous commencerez une transaction. La seule raison pour set autocommit=false si vous voulez forcer une erreur si quelqu'un essaie de lancer une transaction sans commencer.
pour plus de simplicité dans une application Java + MySQL typique d'aujourd'hui, je voudrais plus ou moins ignorer le paramètre auto-commit, utiliser un modèle open-session-In-view et l'appeler bon.
Je découragerais fortement les serrures de rang RDBMS explicites et utiliserais plutôt des serrures optimistes. Hibernate offre un support intégré pour les serrures optimistes, mais c'est un modèle facile à adopter, même pour le code roulé à la main et offre une meilleure performance.
seule raison raisonnable que je peux voir est de se débarrasser de la connection.commit() et connection.rollback() boilerplate dans les transactions simples de requête simple dans les petites applications. JDBC dans la forme brute exige déjà par lui-même beaucoup de boilerplate. Chaque ligne de moins rend JDBC moins effrayant pour les débutants.
Je cours presque toujours avec autocommit=true. 99% du temps, mes mises à jour sont atomiques. Bien sûr, il ya des cas où si vous écrivez le débit et puis échouer en essayant d'écrire le crédit que vous voulez faire reculer. Mais d'après mon expérience, ils sont relativement rares. Habituellement, chaque disque que j'écris se tient seul. Dans ce cas, pas besoin de s'embêter à faire un commit après chaque écriture est pratique. Il enregistrer une ligne de code ici et là. Elle peut économiser plus que cela si, compte tenu de la structure de la programme, cela signifie que je n'ai pas besoin d'un bloc d'essai/capture supplémentaire ou que je n'ai pas besoin de passer un objet de connexion entre les fonctions. Il sauve sur les bogues ennuyeux où quelqu'un a oublié de faire un commit.
la seule façon que je vois que cela pourrait "attirer quelqu'un en difficulté" est qu'il décide que tourner autocommit off et faire le commit ou le rollback est trop de problèmes et donc il fait des mises à jour qui devraient être dans une transaction individuellement. Alors tout semble bien fonctionner tant que rien ça devrait annuler la transaction. Si les scénarios d'essai sont inadéquats, je pourrais imaginer que cela se glisserait dans la production.
mais on peut dire la même chose de presque n'importe quelle caractéristique d'une langue. Comme, supposons que vous écrivez un programme qui traite des nombres que 90% du temps tiendra dans un long, mais de temps en temps peut être plus grand. Face à cette situation, la bonne chose à faire est D'utiliser BigInteger ou de créer une nouvelle classe pour gérer les plus grands nombres. Un programmeur paresseux pourrait être attiré en utilisant long parce que cela fonctionnera généralement et d'autres alternatives sont trop de problèmes. Pourriez-vous donc conclure que Java ne devrait pas inclure ceux de long (ou int) parce que quelqu'un pourrait être incité à les utiliser alors qu'ils ne sont pas appropriés?
si dans vos programmes la majorité des mises à jour doivent être faites dans un contexte de transaction, alors désactivez autocommit. Sa présence ne vous blesse pas. Il est là pour quand il est commode, mais quand il n'est pas vous pouvez l'éteindre.
auto-commit est pratique, mais avec les modifications apportées à la spécification JDBC 3, elle est devenue beaucoup moins utile.
depuis JDBC 3connections en mode "auto-commit" ne peut pas avoir plus d'une déclaration ouverte. L'exécution d'une autre instruction fermera la première -- y compris tout ensemble de résultats.
ainsi, la boucle à L'intérieur d'un SELECT et l'émission de mises à jour (ou même des SELECTs emboîtés) auront tendance à échouer. Apparemment, c'est un crime, de vouloir le faire!--5-->faire quelque chose les résultats de votre outer SELECT!
en tout cas, cela dépend du pilote spécifique et de la version.. mais en général, la spécification JDBC 3 semble rendre ce comportement inutile. La mise à niveau des conducteurs peut également "découvrir" ce comportement sans le vouloir.
Pourquoi utiliser auto-commit? À l'origine, il était utile et pratique. Comme d'autres réponses le disent, JDBC exige beaucoup de GUFF et de manipulation pour appeler correctement.. JDBC n'est pas vraiment une API bien conçue : (
Ces days, vous feriez mieux D'utiliser Hibernate ou Jdbctemplate de Spring.. Et si vous faites des servlets/applications web, placez votre gestion de transaction (début/fin) ou session D'hibernation (liez-la à un thread-local) aux limites de la "demande de L'utilisateur".
par exemple, obtenir lier votre connexion/transaction au début de la ServletRequest; et le retourner à la fin.
Vous pouvez utiliser un javax.servlet.Filtre ou similaire, et le lier à un thread local, apporter une assistance statique pour l'obtenir ou require c', etc.
le mode de propagation change la façon dont le frein rhéostatique retient les serrures.
il est conseillé de désactiver le mode de propagation automatique uniquement pendant le mode de transaction. De cette façon, vous évitez de maintenir des serrures de base de données pour les déclarations multiples, ce qui augmente la probabilité de conflits avec d'autres utilisateurs.
...
pour éviter les conflits pendant une transaction, un SGBD utilise des serrures, des mécanismes pour bloquer l'accès par d'autres personnes aux données qui sont accédées par le transaction. (Notez que dans le mode auto-commit, où chaque instruction est une transaction, les serrures sont conservées pour une seule instruction.)
http://download.oracle.com/javase/tutorial/jdbc/basics/transactions.html
95% de la base de codes avec laquelle je travaille implique maintenant des mises à jour simples où l'autocommit on est parfaitement raisonnable. Donc, nous avons, par défaut. Uniquement éteignant assez longtemps pour faire les sections de code qui doivent être d'une transaction, puis autocommit remonte sur!
Eh bien, il y a certaines conditions qui doivent être examinées attentivement tout en permettant l ' "auto-commit" au niveau mondial:
A.) La gestion des transactions au niveau de la requête sera laissée à l'utilisateur, pour une instance si l'on a besoin d'un tas de requêtes pour réussir ou échouer ensemble, alors il doit être enveloppé sous la transaction BEGIN et commit.
B.) Rappelez-vous qu'il n'y a pas de retour en arrière lorsque "auto-commit" est activé.
C.) Il y a aussi un au-dessus de l'écriture (en commettant) chaque transaction.
D.) Pour les requêtes en lecture seule, il n'y a pas de besoin explicite d ' "auto-commit" mais en activant "auto-commit" il est automatiquement appliqué pour toutes les requêtes.
si le verrouillage de table est la seule préoccupation pour activer l'auto-commit alors ce n'est peut-être pas une bonne idée, on peut plutôt recourir à des temps d'attente de verrouillage plus bas.