One of the additional things about transaction management best practices---- "Every request, one database connection, one transaction" is Jin Ke Yulu?
PrefaceAfter the article "Comprehensive Analysis of transaction management best practices" is published, there are still some outstanding words about the best practices of transaction management. Today I think of some more, so I wrote this article and supplemented it. I don't know if there will be other "Additional Words ". In order to avoid writing the title of a later article as "the best practice of transaction management is more redundant" and "more redundant"... Therefore, the title of this article is "one of the superfluous things of transaction management best practices". I don't know if there will be two or three more.
Is "every request, database connection, and transaction" a golden rule?In the article "Comprehensive Analysis of transaction management best practices", I once said that the best transaction management mode is "every request, a database connection, and a transaction ". Is this rule strictly enforced? No! "Each request, one database connection, and one transaction" is just a general principle, indicating that our database connection and transactions are within the scope of a request and should be as long as possible. You do not have to follow this principle. All principles and theories are only the ideological weapons that guide your work. They are by no means a constraint on you. You can flexibly handle specific situations. You can do this: "Each request, multiple database connections, multiple transactions ".
See the following example:1. This is a controller method of springmvc. On the front-end page, a multi-choice box is displayed, and multiple workflows to be deleted are selected. The parameter passed is the name of each workflow. Here, the transaction method of the service class is called in a loop: uninstalljbpmprocessdefinitionstransaction (Names [I]) to uninstall the business program definition of jbpm, and all its instances and tasks. /*** Delete the selected business program definition on this page *
@ ParamRequest *
@ ParamResponse *
@ Return*
@ ThrowsException */
PublicModelandview uninstall (httpservletrequest request, httpservletresponse response, processdefinitionnames command)
ThrowsException {/*** 1, the name of the selected workflow. */String [] names = command. getnames ();
For(
IntI = 0; I <names. length; I ++ ){
This. Getuninstallprocessdefinition (). uninstalljbpmprocessdefinitionstransaction (Names [I]);}
Return
NewModelandview (urlmap.
Map("Manage. uninstallprocessdefinition. Uninstall");} (2) This is a service-related method (1) this is a service-class transaction method. The Hibernate session is created and closed, and the transaction is also processed. /* (Non-javadoc) * @ see COM. withub. Common. util. iuninstallprocessdefinition # uninstalljbpmprocessdefinitionstransaction (Java. Lang. String )*/
Public
VoidUninstalljbpmprocessdefinitionstransaction (string name) {jbpmcontext = jbpmconfiguration.
Getinstance(). Createjbpmcontext ();
Try{
This. Uninstalljbpmprocessdefinitionsdao (name );}
Finally{Jbpmcontext. Close () ;}} (2) This is the method used to detach the business program definition using the hibernate data access method. The Controller layer cannot directly call it because it does not provide code to process the "get and close database connections, manage transactions" task. /****
@ ParamName */
Private
VoidUninstalljbpmprocessdefinitionsdao (string name) {jbpmcontext = jbpmconfiguration.
Getinstance(). Getcurrentjbpmcontext (); graphsession = jbpmcontext. getgraphsession (); List processdefinitions = graphsession. findallprocessdefinitionversions (name );
If(Processdefinitions! =
Null) {Iterator = processdefinitions. iterator ();
While(Iterator. hasnext () {graphsession. deleteprocessdefinition (processdefinition) iterator. Next () ;}} log.info ("Uninstall workflow:" + name );}
ExampleIn the above example, In the controller, every loop repeats the code "getting and closing database connections and managing transactions. Therefore, it violates the principle of "every request, one database connection, and one transaction. In accordance with this principle, we need to re-write a transaction method in the service class to put all loops in try blocks. Only one database connection and transaction are used. Of course you can. However, there is no problem with the above Code. If an exception occurs during the execution of the Controller method, some jbpm workflow definitions (I call them "Business Program Definitions") may be uninstalled, and some may not. However, this will not undermine the integrity and correctness of the data in the database. The only problem with the above Code is that the database connection is obtained and closed too frequently. However, according to the business logic of this controller method, we know that this loop is not too large. Because there are not many definitions of the business program to be uninstalled. In addition, the front-end page of this function is paginated, so too many business program definitions will not be uninstalled at a time. Therefore, this problem is not very serious. In this case, based on the pragmatic principle, I do not intend to modify the above Code. In this way, I have reduced the trouble of writing a service class transaction method. The current transaction method is originally developed. (Developed for a command line uninstall tool)
ConclusionThis "superfluous word" is intended to prevent readers from going to extremes. Between idealism and reality, we should look at the problem and solve the problem in a realistic way. "Whether it's a white cat or a black cat, it's a good cat to catch a mouse "! Of course, in real life, I still hope that you can think more deeply, always keep the spirit of "excellence", and ask more why and how to do better. In this way, we can help you further improve. I remember Steve McConnell, author of code Daquan, once said (I don't remember the original words, which is probably what I mean below): What a programmer can achieve, it can be seen from the first year of his career. A programmer should have been competent for most jobs after one year of employment. If he no longer pursues better coding, he just needs to pass through and eat his books, then this programmer will always be a cainiao-level programmer no matter how many years he has worked. If a programmer remains eager to learn after two years of employment, his future will be limitless! I hope you are the latter. Of course, if you want to switch to management, you will be brighter if you choose the former!
