--- "Shapira, Yoav" <[EMAIL PROTECTED]> wrote: > > Hi, > I'll forward to the list -- let's continue the discussion there ;) > > Yoav Shapira > Millennium ChemInformatics > > > >-----Original Message----- > >From: Robinson, Jim > >Sent: Monday, November 10, 2003 12:46 PM > >To: Shapira, Yoav > >Subject: RE: [DbUtils] Commit flag on QueryRunner > > > >Yoav, I will subscribe. I clicked a link for the mailing list on the > site > >and it was dead, I will try again. > > > >I'm not sure David understands how the container managed transactions > or > >the JTA works. When using either of these you don't want to manage > commit > >at the connection level, this largely defeats there purpose. In the > case > >of container managed transactions (EJB bean) the container makes the > >commit() calls when exiting the method demarcating the transaction. If > a > >runtime (uncaught) exception occurs the container rolls back the > >transaction. The user can also control this but that's usually not > >recommended.
You're right, I've never used EJB or JTA so this information is helpful. How would the update() method look for JTA use? Obviously, QueryRunner isn't currently designed for this use case. One reason we changed these methods to normal members instead of statics is to allow subclasses to override their behavior. Wouldn't it be trivial to create a JTA enabled QueryRunner subclass that just overrides the update() method for your purposes? I'm not a big fan of flags changing class behavior like the proposed solution because it leads to messy if/else statements. David > > > >In the case of the JTA. The user starts a transaction and ends it > >explicitly, but in between many updates might be performed. (This only > >works with a transaction data source where connections are wrapped and > >closing simply makes them available again). > > > >I realize that I can do this by using the method that passes in the > >connection but this is ugly and really shouldn't be necessary. This > >package would be much more useful to EJB & JTA developers if the > commits, > >etc, could be turned off. As it is it assumes that either (1) the user > >will manage the transaction by explicitly managing connections, or (2) > a > >transaction will not span multiple updates. > > > >To answer David's question explicitly ... > > > >>> If you disabled the commit and rollback in these methods, > >>>how would you handle the transactions manually without access to the > >>>Connection?.. > > > >The answer is you don't need to. The container will do that for you > when > >the transaction ends, assuming you are using the container managed > >Datasource of course. > > > >If I haven't explained this very very well come on down, I can do a > better > >job at the whiteboard. __________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
