ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rajaram_Viswanathan" <Rajaram_Viswanat...@Satyam.com>
Subject RE: Ibatis Transactions across multiple DAO objects
Date Tue, 02 May 2006 14:18:03 GMT
Hello Poitras,
Thanks for investing time to answer my query.
After debugging I found that the problem is not with the ibatis transactions.
The culprit is Stored procedure which does implicit commit:-(.
Sorry for the confusion.
 
Regards,
Rajaram V

________________________________

From: Poitras Christian [mailto:Christian.Poitras@ircm.qc.ca]
Sent: Tue 5/2/2006 7:30 PM
To: user-java@ibatis.apache.org
Subject: RE: Ibatis Transactions across multiple DAO objects


I am curious about what causes the problem.
I haven't used stored procedures for a long time.
 
First, you should check if the procedure can be rolled back (this problem could occur in the
JDBC driver instead of the database).
A good check could be to make those calls in hard coded sql temporarelly in a java class and
see if the JDBC driver can roll back in the consistent way you wan't.
If it doesn't work, iBatis is not in cause and maybe you should update your drivers or contact
the database compagny.
 
If it's iBatis, I can't help you any further, I'm sorry.

________________________________

From: Rajaram_Viswanathan [mailto:Rajaram_Viswanathan@Satyam.com] 
Sent: Tuesday, 02 May 2006 01:38
To: user-java@ibatis.apache.org
Subject: RE: Ibatis Transactions across multiple DAO objects


Hello,
Any idea on this issue?

________________________________

From: Rajaram_Viswanathan
Sent: Fri 4/28/2006 4:27 PM
To: user-java@ibatis.apache.org
Subject: FW: Ibatis Transactions across multiple DAO objects


 

________________________________

From: Rajaram_Viswanathan
Sent: Fri 4/28/2006 12:22 PM
To: user-java@ibatis.apache.org
Subject: Ibatis Transactions across multiple DAO objects


Hello All,
I wanted to control  ibatis transactions manually in my application.
I had used daoManagaer.StartTransaction/endTransaction().
Following is the code:
This code is in a service class which would be called by the action class to do insert operations
 

class Myservice extends BaseService{

public Bean insertPrimaryContent(Bean bean)
   {
   try{
    daoManager.startTransaction();

//This function is available in the base service class using the baseDao object obtained 
   

//using getDao(BaseDao.class)   method    in    base service.       

super.callGenericInsertStoredProc();

     //Updations are done seperately on the inserted data.

     //This below functions are in this class and uses myDao obtained using getDao(MyDao.class)
method in category   service

     UpdateRelatedProperities();  //Mark 1

     UpdateRelatedTables();         //Mark 2

      .....
     daoManager.commitTransaction();
 }finally{
 daoManager.endTransaction();
 }
   
  return bean;
 }

}

 

Since I handle transactions manually,commit is not done in my stored procs.

But if any of the exception occurs at Mark 1 or Mark 2(see comments) ,The operations done
by the callGenericInsertStoredProc() is not rolled back but mark1 and mark2 operations are
rolled back.

Can you please tell me how to solve this problem?

I want all the above things to happen as single atomic transaction(All or None).

Please let me know if you have solution for the above problem.

 

DISCLAIMER:
This email (including any attachments) is intended for the sole use of the intended recipient/s
and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review
or reliance by others or copying or distribution or forwarding of any or all of the contents
in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact
the sender by email and delete all copies; your cooperation in this regard is appreciated..



DISCLAIMER:
This email (including any attachments) is intended for the sole use of the intended recipient/s
and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review
or reliance by others or copying or distribution or forwarding of any or all of the contents
in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact
the sender by email and delete all copies; your cooperation in this regard is appreciated.

Mime
View raw message