Howdy, It does seem like a good, simple solution -- cool. Yoav Shapira Millennium ChemInformatics
>-----Original Message----- >From: Steven Caswell [mailto:[EMAIL PROTECTED] >Sent: Monday, November 10, 2003 7:22 PM >To: 'Jakarta Commons Developers List' >Subject: RE: [DbUtils] Commit flag on QueryRunner > >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] 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]
