You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by "Nikhil G. Daddikar" <ng...@celoxis.com> on 2002/03/30 12:12:29 UTC

Sharing one connection across objects

Hi Folks,

We are moving to using turbine from our home-grown "framework" and have been quite pleased.

However I have a few questions. Here is one of them:

    While handling a web request, a bunch of java objects do database calls over jdbc. I want to do this in a
transaction => use the same connection in all the jdbc calls.

Currently we have a per-web-request context object that has the dbconnection object in it. RunData doesn't seem to have
it. What is the 'turbine recommended' way?

Thanks much!
-ngd.



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Sharing one connection across objects

Posted by Rodney Schneider <rl...@arcalink.com>.
> "Nikhil G. Daddikar" wrote:
> > Hi Folks,
> >
> > We are moving to using turbine from our home-grown "framework" and have
> > been quite pleased.
> >
> > However I have a few questions. Here is one of them:
> >
> >     While handling a web request, a bunch of java objects do database
> > calls over jdbc. I want to do this in a transaction => use the same
> > connection in all the jdbc calls.
> >
> > Currently we have a per-web-request context object that has the
> > dbconnection object in it. RunData doesn't seem to have it. What is the
> > 'turbine recommended' way?

Are you using Torque and Peers?  If so, you will notice in the generated 
classes that you can pass in a DBConnection object to all methods that access 
your database.  You will also notice that the methods in BasePeer (doSelect, 
doInsert, doUpdate, doDelete) handle transactions for you by calling 
transaction handling methods in BasePeer (beginTransaction(), 
commitTransaction() and rollBackTransaction()).

If you are going to implement your own RunData to provide a per-web-request 
DBConnection object in it, you will need to do the transaction handling 
yourself.  See the following code for an example of how to use the Turbine 
connection pool...

----------

import java.sql.Connection;
import org.apache.turbine.services.db.TurbineDB;
import org.apache.turbine.util.db.pool.DBConnection;

try {
   // get a connection from the pool
   DBConnection dbConn = TurbineDB.getConnection();
   // start the transaction
   dbConn.setAutoCommit(false);

   // the following line may be necessary if you are not using Torque...
   Connection connection = dbConn.getConnection();
   ...
   // perform your database calls here
   ...
   // commit the transaction
   dbConn.commit();
   dbConn.setAutoCommit(true);
} catch (Exception e) {
   // rollback the transaction
   dbConn.rollback();
   dbConn.setAutoCommit(true);
}
finally {
   // release the connection back to the pool
   try {
      TurbineDB.releaseConnection(db);
   } catch (Exception ignored) {}
}

----------

Hope this helps,

-- Rodney

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Sharing one connection across objects

Posted by John McNally <jm...@collab.net>.
You can create your own RunData object or you could just set the
connection as a request attribute.

john mcnally

"Nikhil G. Daddikar" wrote:
> 
> Hi Folks,
> 
> We are moving to using turbine from our home-grown "framework" and have been quite pleased.
> 
> However I have a few questions. Here is one of them:
> 
>     While handling a web request, a bunch of java objects do database calls over jdbc. I want to do this in a
> transaction => use the same connection in all the jdbc calls.
> 
> Currently we have a per-web-request context object that has the dbconnection object in it. RunData doesn't seem to have
> it. What is the 'turbine recommended' way?
> 
> Thanks much!
> -ngd.
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>