Looks like a good solution. +1
Steven Caswell Sun Certified Java Programmer [EMAIL PROTECTED] a.k.a Mungo Knotwise of Michel Delving "One ring to rule them all, one ring to find them..." > -----Original Message----- > From: Robinson, Jim [mailto:[EMAIL PROTECTED] > Sent: Monday, November 10, 2003 3:05 PM > To: Jakarta Commons Developers List > Subject: RE: [DbUtils] Commit flag on QueryRunner > > > > > > >-----Original Message----- > >From: David Graham [mailto:[EMAIL PROTECTED] > >Sent: Monday, November 10, 2003 2:44 PM > >To: Jakarta Commons Developers List > >Subject: RE: [DbUtils] Commit flag on QueryRunner > > > > > >--- "Robinson, Jim" <[EMAIL PROTECTED]> wrote: > >> > >> David, I agree with you regarding flags. This is a very nice > package, I > >> didn't mean to be critical. > > > >I wasn't offended; we need as many people reviewing the code as > possible. > >Thanks for your input. > > > >> > >> I've only used EJBs and JTA, I've not been a developer so > I may have > >> some details wrong. Others on this list can no doubt > correct me. To > >> use either of these you need a transactionally aware data > source. I > use > >> JBoss which includes such a datasource. All EJB containers provide > one. > >> For Tomcat I think you can use Tyrex, never tried. > >> > >> At any rate transactional aspects of connections (commit, rollback) > are > >> managed by the container. A transaction is started either > upon entry > of > >> a demarcated EJB method (container managed transaction) or by > explicit > >> use of the UserTransaction interface > >> > (http://java.sun.com/products/jta/javadocs-1.0.1/javax/transac > tion/UserT > >> ransaction.html). In the latter case you do something like > >> > >> userTransaction.begin(); > >> > >> The transaction is completed upon exit of the demarcated > EJB method > >> (container managed) or, if doing explicity transactions, > by something > >> like > >> > >> userTransaction.commit() or userTransaction.rollback() > >> > >> Any database updates performed in between these events are > associated > >> with the transaction and will be committed or rolled back together. > You > >> can, and often do, make many calls to > datasource.getConnection() and > >> connection.close() in between. > > > >That answered my next question :-). > > > >> So you have decoupled the connection > >> management from transaction management. This is a very > nice model to > >> work with, especially the container managed version. In that case > there > >> is no explicit transaction management in the code and you can > rearrange, > >> split, group transactions with ease. The explicit version > >> (UserTransaction) is slightly less nice because the explicity > boundaries > >> are in the code, but still much more flexible than doing it at an > >> individual connection/update level. > >> > >> So how does this work since ultimately it is done at the jdbc > connection > >> level? Well, as I said I have not worked on implementation of > >> containers. I have however worked on emulations of them for > development > >> test frameworks. One way to accomplish this is to keep a map of > >> connections in your DataSource implementation with the > thread as the > >> key. When a transaction is started you get a connection from the > pool > >> and store it in the map. When the transaction ends you remove the > >> thread key from the map. In between getConnection() looks > in the map > >> for a connection and if it finds one that is returned. > I've left out > >> some details and real Containers are surely more sophisticated, but > that > >> is a possible implementation. > >> > >> Of course none of this works if you do explict calls to > setAutoCommit, > >> commit, rollback, etc. In fact, you will get an exception if using > some > >> of these methods with a transactionally aware datasource > if within a > >> managed transaction. > >> > >> Hopefully I've not mangled this explanation beyond > comprehension. If > I > >> have perhaps someone could clarify. Basically you cannot hijack > >> container managed transactions by doing explict commits. Removing > the > >> calls to commit, rollback, and setAutocommit would make the update > >> methods perfectly compatible with either EJB managed > transactions or > >> UserTransaction. If you can figure out a way to get this > it would be > >> very helpful to those of use using containers for transactions. In > the > >> meantime I will probably try to subclass QueryRunner and > override the > >> update methods. > > > >So maybe the best thing to do is remove those calls. The Connection > will > >have to be in auto-commit mode or you must be using > something like JTA > >that handles transactions. There's nothing to rollback anyways since > it's > >only a single update statement executing. If an > SQLException is thrown > >during the update it obviously won't be committed and there are no > other > >changes to rollback. > > > >Comments? > > > >David > > > > Brilliant, I think that is the solution. > > Jim > > > > > This e-mail, including any attachments, is a confidential > business communication, and may contain information that is > confidential, proprietary and/or privileged. This e-mail is > intended only for the individual(s) to whom it is addressed, > and may not be saved, copied, printed, disclosed or used by > anyone else. If you are not the(an) intended recipient, > please immediately delete this e-mail from your computer > system and notify the sender. Thank you. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
