We don't currently have a singleton for the mapper, but I'm thinking you would need to in order to do that. My other concern would be making it thread safe in the singleton.
I really don't like this path, but we're considering a custom build of iBatis to add the property to the session and fix the boolean field since that seems to be the simplest solution by far. I guess I need to get on the dev list and see if they are open to adding this. If they are, I'd feel better about a custom build that would be a stop gap until it gets in an official build. -----Original Message----- From: Bob Hanson [mailto:[EMAIL PROTECTED] Sent: Friday, February 23, 2007 8:21 AM To: [email protected] Subject: Re: Checking for Open Transactions That's how I currently have it implemented. If you are using a singleton for your mapper, you could probably cache it there as well. On 2/23/07, Clough, Samuel (USPC.PRG.Atlanta) <[EMAIL PROTECTED]> wrote: > If I understand your approach, that will only work if all methods are in > the same class, correct? > > -----Original Message----- > From: Bob Hanson [mailto:[EMAIL PROTECTED] > Sent: Thursday, February 22, 2007 3:37 PM > To: [email protected] > Subject: Re: Checking for Open Transactions > > It looks like_isOpenTransaction is never set to false once it becomes > true. So adding a property is not enough. > > Right now I have decided to hold on to an instance of ISqlMapSession > when I start a transaction that I want to share across method calls. > If my session instance is not null, I use that session. If it is null, > I start a new local transaction instead. > > On 2/16/07, Clough, Samuel (USPC.PRG.Atlanta) > <[EMAIL PROTECTED]> wrote: > > > > > > > > Ok, nobody replied which confuses me a little. I find it very hard to > > believe that I'm the only one that has had this problem. So far I > haven't > > found a good solution. > > > > The perfect solution is almost there in the Session. It has a field > > tracking if there is an open session. If someone would wrap a > property > > around this field, the problem would be solved. > > > > I also thought about checking the Transaction property to see if it's > null, > > but that's no reliable because the rollback transaction method calls > set the > > transaction to null, but the commit method calls do not set the > transaction > > to null. > > > > Unless there is something else I've missed here, can a property be > added > > around the _isOpenTransaction field in the SqlMapSession? I would say > it > > should be added to the interface as well. Since it abstracts > transactions, > > it should abstract the ability to check for a transaction IMHO. > > > > ________________________________ > > From: Clough, Samuel (USPC.PRG.Atlanta) > > Sent: Monday, February 12, 2007 8:14 AM > > To: [email protected] > > Subject: Checking for Open Transactions > > > > > > > > Maybe I'm missing something really obvious here, but I don't see a way > on > > the SqlMapper to check to see if a transaction is open before starting > one. > > To me (and a couple other devs here using iBatis), this is an obvious > need > > because you may have a class call several methods to execute several > > statements. When a method is called, it's very helpful for that > method to > > be able to check to see whether or not it needs to open a transaction. > Is > > there a solution here I'm just not seeing, or has this by chance been > added > > in SVN? Am I missing something here? > > > > ________________________________ > > > > > > > > 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. > > ________________________________ > > > -------------------------------------------------------- > > 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. > > -------------------------------------------------------- >
