As far as I know, you can use the solution of Samuel Clough: In the repository classes check if a transaction is opened. If not:
create the transaction, do the insert/update/delete/query and finish with commit(true) (this closes the transaction). This is the same solution like the one you have now. Then, in your service class you can open a transaction, call the repository methods and then finish with commit (inside the service). With this, the repository check if a transaction is opened. Because it is, then the repository classes just do the inserts/updates/.../ and finish without commit, that is made through the service. It's just an idea, don't know if this works :S Greetings and sorry for my poor english! 2008/7/1 Sal Bass <[EMAIL PROTECTED]>: > Understood, but I am not interacting with Ibatis directly in my service > layer. My repository classes contain the code that interacts with Ibatis. > So, in my service layer I may need to have one transaction that spans calls > to more than one repository class. > > Like: > > Repository1.Save(obj); > Repository2.Save(obj); > > But all wrapped in one transaction. > > >> Subject: RE: Managing Transactions >> Date: Tue, 1 Jul 2008 10:15:01 -0400 >> From: [EMAIL PROTECTED] >> To: [email protected] >> >> We do basically the same thing with a quick check before the >> BeginTransaction call to see if a transaction is already open or not. >> In the same respect, if one was open before the method call then the >> method doesn't commit either thus allowing the original method call to >> control the transaction lifecycle. >> >> This allows several method calls to effectively be encapsulated in the >> same transaction while still using iBatis semantics. >> >> -----Original Message----- >> From: Juan Pablo Araya [mailto:[EMAIL PROTECTED] >> Sent: Monday, June 30, 2008 11:18 AM >> To: [email protected] >> Subject: Re: Managing Transactions >> >> Hope I have understood your question. We use for transactions >> (specially for rollback the entire insertion/updates in case of error) >> the following >> >> >> ISqlMapper sqlMapper = Mapper.Instance(); >> sqlMapper.BeginTransaction(); >> >> try { >> ... our inserts/updates/deletes directly goes here. For example, if >> the class User has his own method User.Save() that uses iBatis, just >> copy & paste the insert statement here: >> >> sqlMapper.Insert("InsertUser", userObject); >> >> in replace of >> >> (Class User) sqlMapper.Insert("InsertUser", this); >> >> ... another insertions >> ... >> if(some logical business error) >> throw new Exception("Error in some part"); >> >> // If everithing OK: >> sqlMapper.CommitTransaction(true); >> } >> catch (Exception ex) { >> sqlMapper.RollBackTransaction(true); >> throw ex >> } >> >> >> >> 2008/6/30, Vincent Apesa <[EMAIL PROTECTED]>: >> > >> > >> > Sal, >> > In our application we wrap calls the repository using the >> System.Transactions built into .Net 2.0 in the Service layer. It works >> across multiple databases and manages a few other types of operations as >> well (email..etc). >> > >> > Vince >> > >> > >> > ________________________________ >> From: [EMAIL PROTECTED] >> > To: [email protected] >> > Subject: Managing Transactions >> > Date: Sun, 29 Jun 2008 17:53:56 -0400 >> > >> > >> > >> > Hello, >> > >> > In my application, I am using ibatis inside my repository classes. I >> interact with the repository classes in my service layer, and am >> wondering if there is anything special I need to do to managing >> transactions. Meaning, in my service layer classes, can I just wrap >> calls to repository methods inside a TransactionScope? Or, is there a >> another suggested pattern for doing this? I will need to have multiple >> calls to different repository methods in one transaction. >> > >> > Thanks, >> > Sal >> > >> > ________________________________ >> The other season of giving begins 6/24/08. Check out the i'm >> Talkathon. Check it out! >> > ________________________________ >> Earn cashback on your purchases with Live Search - the search that >> pays you back! Learn More >> -------------------------------------------------------- >> >> Princeton Retirement Group, Inc - Important Terms >> This E-mail is not intended for distribution to, or use by, any person or >> entity in any location where such distribution or use would be contrary to >> law or regulation, or which would subject Princeton Retirement Group, Inc. >> or any affiliate to any registration requirement within such location. >> This E-mail may contain privileged or confidential information or may >> otherwise be protected by work product immunity or other legal rules. No >> confidentiality or privilege is waived or lost by any mistransmission. >> Access, copying or re-use of information by non-intended or non-authorized >> recipients is prohibited. If you are not an intended recipient of this >> E-mail, please notify the sender, delete it and do not read, act upon, >> print, disclose, copy, retain or redistribute any portion of this E-mail. >> The transmission and content of this E-mail cannot be guaranteed to be >> secure or error-free. Therefore, we cannot represent that the information in >> this E-mail is complete, accurate, uncorrupted, timely or free of viruses, >> and Princeton Retirement Group, Inc. cannot accept any liability for E-mails >> that have been altered in the course of delivery. Princeton Retirement >> Group, Inc. reserves the right to monitor, review and retain all electronic >> communications, including E-mail, traveling through its networks and systems >> (subject to and in accordance with local laws). If any of your details are >> incorrect or if you no longer wish to receive mailings such as this by >> E-mail please contact the sender by reply E-mail. >> >> -------------------------------------------------------- > > > ________________________________ > Do more with your photos with Windows Live Photo Gallery. Get Windows > Live-Free
