commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Juozas Baliuka" <bali...@centras.lt>
Subject Re: [DbUtils] Commit flag on QueryRunner
Date Mon, 10 Nov 2003 19:15:17 GMT

Hi,
I do not think Commit flag is a good idea.
It must be better to remove transaction demarcation code form QueryRunner.

The best known way is to map connection to Thread (java.langThreadLocal),
JTA uses this way too.

ThreadLocal localConnections = new ThreadLocal();

 public Connection QueryRunner.currentConnection() throws SQLException  {

        Connection c = (Connection)localConnections.get();
        if( c == null ){
            c = ds.getConnection();
            localConnections.set();
          }
        return c;

 }

More "transparent" way is to use Datasource decorator to return ThreadLocal
connections.

It is usefull in container and in standalone application.

I use this way for "stanalone" web and JMS applications, transactions are
managed by command or
message dispatcher.

More "abstract" way to wrapp connection in Transaction:

 void dispatch( Message msg ) throws Exception{

        try{

          Transaction tx = txManager.currentTransaction();

          Handler h = findHandler(msg.getParameter("HANDLER_NAME"));

          tx.begin();

          h.handleMessage(msg);

          tx.commit();

        }finally{
           tx.rollback();
        }

 }


>
> --- "Shapira, Yoav" <Yoav.Shapira@mpi.com> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message