This part is closely linked to DAO.
When we use DAO, as follows, first insert a new record, then update:
Persondao.insertPerson (Person); // Starts Transaction Person.SetlastName ("Begin"); Persondao.UpdatePerson (Person); // Starts A New Transaction
Because there is no explicitly launching business, IBATI will think this is two transactions, and the connecting pool is taken twice. Each DAO method we have written (inherited from com.ibatis.dao.client.template.sqlmapdaotemplate) has default an transaction (through dynamic agent).
In the business layer, there should be a class to unite the DAO subclass, IBATIS is as good as the Daomanager class, as follows:
Daomanager Provides Access To All daos it organs and also allows Transactions to be committed and end (Possibly Rolled Back)
The DAO subclass is produced by daomanager, such as:
Daomanager daomanager = daomanagerbuilder.builddaomanager (reader); userdao userdao = (userdao) Daomanager.class; userDao is the user's own interface, which is actually the corresponding SQLMAPDAO implementation class specified in DAO.XML It is thus achieved loosely. In a good layered design, the service layer (Service package) only needs to know the DAO interface, and don't care about how it is true. If the transaction processing statement is explicitly declared, as follows: try {daomanager.startTransaction (); Person.InsertPerson (Person.SetlastName ("Begin"); Persondao.dosomething (Other); OtherDao.Dosomething (Other); .. Daomanager.commitTransAction ();} finally {daomanager.endtransaction ();} This is maintained atomic, overall is a transaction, or all executes, otherwise rollback. The only problem now is whether the DAO layer has gone, otherwise it will have an impact on performance (worry-free day?) Of course, iBATIS can do this: Built a statement interface: iService, then use dynamic agents, Use the user's own Server subclasses to automatically package the code on the transaction processing by dynamic proxy, and the default is a transaction. If the master's heart can easily speculate, it is not a master :), the estimated master thinks that this is over-design, he believes that this flexibility is handed over to the user is suitable, quite a number of service methods only call a DAO method, such as CRUD operation . Add it, the processing of transactions in iBATI is configurable, the most common type of TYPE is "JDBC", or "JTA" or "External" can also be declared.
