If you do not call start transaction then each update call in the dao class will be in it's own transaction. This means that you would have incomplete data if any of them failed for any reason. If you wrap the call to the accountDao.insertAccount(account); with the transaction... then all of the update calls will be in a single transaction.
Brandon On 5/24/05, Jason Hall <[EMAIL PROTECTED]> wrote: > Correct me if I'm wrong, my understanding is that the call to > startTransactions in the service layer > automatically is aware of the methods to all called dao classes. If the the > startTransaction is not called at all > then those 3 updates in the dao layer are not in the transaction. Therefore > you must call startTransaction in the service layer. > > > -----Original Message----- > From: Lieven De Keyzer [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 24, 2005 4:07 PM > To: ibatis-user-java@incubator.apache.org; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: RE: transactions > > > Yes, I see. But does that mean that I should put every call to a dao that > occurs in the service in a transaction? > If this is the case: > > Service Layer: > > doaManager.startTransaction(); > accountDao.insertAccount(account); > doaManager.commitTransaction(); > .... > finally(){doaManager.endTransaction():} > > Dao Layer: > public void insertAccount(Account account) > { > update("insertAccount", account); > } > > Would this startTransaction() call still be necessary? > > >From: "Jason Hall" <[EMAIL PROTECTED]> > >Reply-To: ibatis-user-java@incubator.apache.org > >To: > ><ibatis-user-java@incubator.apache.org>,<[EMAIL PROTECTED]>,<[EMAIL > >PROTECTED]> > >Subject: RE: transactions > >Date: Tue, 24 May 2005 16:00:11 -0400 > > > >if a an error occurs in any of these 3 updates below > > > > update("insertAccount", account); > > > > update("insertProfile", account); > > > > update("insertSignon", account); > >a rollback will occur before the daoManager.commitTransaction(). > >So isn't it safe to say that these updates a wrapped in the transaction? > >Also doesn't this constitute a valid insert of Account? > > > >Example: > > > >Service Layer: > > > >doaManager.startTransaction(); > >accountDao.insertAccount(account); > >doaManager.commitTransaction(); > >.... > >finally(){doaManager.endTransaction():} > > > >Dao Layer: > >public void insertAccount(Account account) > >{ > >update("insertAccount", account); > >update("insertProfile", account); > >update("insertSignon", account); > >} > > > > > > > >-----Original Message----- > >From: Lieven De Keyzer [mailto:[EMAIL PROTECTED] > >Sent: Tuesday, May 24, 2005 3:48 PM > >To: [EMAIL PROTECTED]; ibatis-user-java@incubator.apache.org; > >[EMAIL PROTECTED] > >Subject: Re: transactions > > > > > > > > > > >From: Clinton Begin <[EMAIL PROTECTED]> > > >Reply-To: [EMAIL PROTECTED] > > >To: ibatis-user-java@incubator.apache.org, Brandon Goodin > > ><[EMAIL PROTECTED]> > > >Subject: Re: transactions > > >Date: Tue, 24 May 2005 13:40:04 -0600 > > > > > >Those update statements ARE in a transaction. But you should NEVER manage > > >transactions inside the DAO. The transaction in this case is taken care > >of > > >outside of the scope of this particular method (I believe in this case it > > >is > > >actually an automatic DAO transaction, so you might not find the calls to > > >start/commit/end). > > > >So, what you mean is: I should make the transaction in my service layer, > >and > >inside this transaction call the dao method. But if I change a method in my > >DAO, to have multiple statements, I would also need to change my Service > >class, to place the call in a transaction? > >And how does one specify those automatic transactions? > > > > > >Clinton > > > > > >On 5/24/05, Brandon Goodin <[EMAIL PROTECTED]> wrote: > > > > > > > > Message was sent to me privately... so i am posting it to the list > > > > ----- > > > > But for example, in the JPetStoreExample, in the AccountSqlMapDao, > >this > > >is > > > > a > > > > method: > > > > > > > > public void insertAccount(Account account) { > > > > update("insertAccount", account); > > > > update("insertProfile", account); > > > > update("insertSignon", account); > > > > } > > > > > > > > Aren't those different update statements better off in a transaction? > > >And > > > > why no different calls from the Service layer? > > > > I'm just trying to understand the difference. > > > > > > > > >From: Brandon Goodin <[EMAIL PROTECTED]> > > > > >Reply-To: Brandon Goodin <[EMAIL PROTECTED]> > > > > >To: ibatis-user-java@incubator.apache.org > > > > >Subject: Re: transactions > > > > >Date: Tue, 24 May 2005 12:45:59 -0600 > > > > > > > > > >It is not neccessary to call transactions on only one statement. > > > > > > > > > >Transactions should be handled on the Service layer and make more > > > > >fine-grained calls to the DAO layer. > > > > > > > > > >Brandon > > > > > > > > > >On 5/24/05, Lieven De Keyzer <[EMAIL PROTECTED]> wrote: > > > > > > At http://www.reumann.net/struts/ibatisLesson1/step6.do > > > > > > this is an example in a ibatis/struts tutorial > > > > > > > > > > > > public int update(String statementName, Object parameterObject) > > >throws > > > > > > DaoException { > > > > > > int result = 0; > > > > > > try { > > > > > > sqlMap.startTransaction(); > > > > > > result = sqlMap.executeUpdate(statementName, parameterObject); > > > > > > sqlMap.commitTransaction(); > > > > > > } catch (SQLException e) { > > > > > > try { > > > > > > sqlMap.rollbackTransaction(); > > > > > > } catch (SQLException ex) { > > > > > > throw new DaoException(ex.fillInStackTrace()); > > > > > > } > > > > > > throw new DaoException(e.fillInStackTrace()); > > > > > > } > > > > > > return result; > > > > > > } > > > > > > > > > > > > Is it necessary to have a transaction started for just 1 statement > > > > > > execution? > > > > > > > > > > > > Also, what's the better way? Doing a transaction in a Service > >class, > > > > >that > > > > > > has multiple DAO's, or doing it in the DAO class, doing different > > > > >statements > > > > > > in one method? Or is there no difference? > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
