David, I agree with you regarding flags. This is a very nice package, I didn't mean to be critical.
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/transaction/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. 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. Regards, Jim >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 > 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]
