Re-using an existing jdbc connection?

7 Messages Forum Options Options
Permalink
justin_grunau
Re-using an existing jdbc connection?
Reply Threaded More
Print post
Permalink

Is it possible somehow to pass an already-existing jdbc connection (with a transaction already in progress) into OpenJPA?  Most of my application is written in OpenJPA but I have to implement a feature that involves being called with a transaction having started and with a database handle being passed in.  If I can't pass that connection into OpenJPA then I will have to write this part of the application in straight jdbc/SQL, which will involve an unfortunate duplication of logic.

Justin Grunau
Advisory Software Engineer
Software as a Service (SaaS)

IBM Software Group



One Rogers Street
Cambridge, Massachusetts 02142

phone:       +1-617-693-4898 (T/L 693-4898)
fax:            +1-617-693-5748 (T/L 693-5748)
notes:        
Justin Grunau/Cambridge/IBM@Lotus
internet:      
justin_grunau@...

Pinaki Poddar
Re: Re-using an existing jdbc connection?
Reply Threaded More
Print post
Permalink
Hi,
  If OpenJPA is invoked in a managed transaction context, EntityManager.joinTransaction() will make OpenJPA join the existing transaction.
  If there is no managed transaction then you can use a bound the existing JDBC connection to a thread and make OpenJPA use it instead of opening one on its own.


justin_grunau
Re: Re-using an existing jdbc connection?
Reply Threaded More
Print post
Permalink
Thanks very much for the joinTransaction() suggestion.
As for the other suggestion, could you provide more detail on how I could
"make OpenJPA use [the existing JDBC connection] instead of opening one on
its own"? :-)
Thanks a lot!!








Pinaki Poddar <ppoddar@...>
07/02/2008 06:35 PM
Please respond to
users@...


To
users@...
cc

Subject
Re: Re-using an existing jdbc connection?







Hi,
  If OpenJPA is invoked in a managed transaction context,
EntityManager.joinTransaction() will make OpenJPA join the existing
transaction.
  If there is no managed transaction then you can use a bound the existing
JDBC connection to a thread and make OpenJPA use it instead of opening one
on its own.



--
View this message in context:
http://n2.nabble.com/Re-using-an-existing-jdbc-connection--tp210696p219975.html

Sent from the OpenJPA Users mailing list archive at Nabble.com.


Pinaki Poddar
Re: Re-using an existing jdbc connection?
Reply Threaded More
Print post
Permalink
Hi,
  The suggestions are untested, so read/follow it with caution:
Here is a sketch:

   1. JDBCStoreManager is the key interface that OpenJPA kernel uses for JDBC. The following is the key method that JDBCStoreManager uses to get a connection:
   protected RefCountConnection connectInternal() throws SQLException {
        return new RefCountConnection(_ds.getConnection());

   2. Following code outside OpenJPA is executed on thread T
       java.sql.Connection con = // get a connection from a JDBC database
       do some direct JDBC operation with con but do not commit
       ThreadLocal.set(con);

   3. call OpenJPA functions that needs database connection on the same thread T as Step 2.

   4. Extend JDBCStoreManager for the method mentioned in Step 1 say by a class PiggybackStoreManager. The overwritten method simply gets the ThreadLocal variable i.e. the thread-bound JDBC connection con used in Step 2.

   Of course, you need to tell OpenJPA to use PiggybackStoreManager. But that is the easy part. I will do some prototype to see if this approach works at all or more importantly what side-effect it will have with OpenJPA's connection management when someone sneaks a JDBC connection to it.  


    }
justin_grunau wrote:
Thanks very much for the joinTransaction() suggestion.
As for the other suggestion, could you provide more detail on how I could
"make OpenJPA use [the existing JDBC connection] instead of opening one on
its own"? :-)
Thanks a lot!!








Pinaki Poddar <ppoddar@apache.org>
07/02/2008 06:35 PM
Please respond to
users@openjpa.apache.org


To
users@openjpa.apache.org
cc

Subject
Re: Re-using an existing jdbc connection?







Hi,
  If OpenJPA is invoked in a managed transaction context,
EntityManager.joinTransaction() will make OpenJPA join the existing
transaction.
  If there is no managed transaction then you can use a bound the existing
JDBC connection to a thread and make OpenJPA use it instead of opening one
on its own.



--
View this message in context:
http://n2.nabble.com/Re-using-an-existing-jdbc-connection--tp210696p219975.html

Sent from the OpenJPA Users mailing list archive at Nabble.com.

Patrick Linskey-2
Re: Re-using an existing jdbc connection?
Reply Threaded More
Print post
Permalink
In reply to this post by justin_grunau
Hi,

What environment are you executing your code in? Is this a Java EE  
app? The easiest way is to put a DataSource into JNDI, configure your  
transaction manager appropriately, and put OpenJPA into "managed  
transaction" mode. In this configuration, the semantics of Connection  
delivery will be up to the DataSource implementation.

If you don't have a transaction manager handy, you can create a  
DataSource implementation that meets your semantics, and provide it to  
OpenJPA when you create your EntityManagerFactory.

-Patrick

On Jul 2, 2008, at 5:39 PM, justin_grunau@... wrote:

> Thanks very much for the joinTransaction() suggestion.
> As for the other suggestion, could you provide more detail on how I  
> could
> "make OpenJPA use [the existing JDBC connection] instead of opening  
> one on
> its own"? :-)
> Thanks a lot!!
>
>
>
>
>
>
>
>
> Pinaki Poddar <ppoddar@...>
> 07/02/2008 06:35 PM
> Please respond to
> users@...
>
>
> To
> users@...
> cc
>
> Subject
> Re: Re-using an existing jdbc connection?
>
>
>
>
>
>
>
> Hi,
>  If OpenJPA is invoked in a managed transaction context,
> EntityManager.joinTransaction() will make OpenJPA join the existing
> transaction.
>  If there is no managed transaction then you can use a bound the  
> existing
> JDBC connection to a thread and make OpenJPA use it instead of  
> opening one
> on its own.
>
>
>
> --
> View this message in context:
> http://n2.nabble.com/Re-using-an-existing-jdbc-connection--tp210696p219975.html
>
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
>
--
Patrick Linskey
202 669 5907



smime.p7s (3K) Download Attachment
justin_grunau
Re: Re-using an existing jdbc connection?
Reply Threaded More
Print post
Permalink
The environment is tomcat.  Our database is a JNDI datasource.
My application as it exists today is written ENTIRELY in openJPA.
Different applications in our project use different methods to talk to
databases.  Ours is the only one that uses openJPA.
I have to implement a new feature which involves me adding a servlet to my
webapp:  the task requires that I subclass an existing base class servlet,
which was written in straight JDBC + SQL.  When I write my subclass, I
will override a method.  When this method is invoked, I am supposed to
perform certain database changes.
The base class of my servlet is written to get a database connection and
start a transaction.  By the time MY class is called, the transaction is
already in progress.
I have no idea what constitutes a "managed" transaction.  This terminology
kind of smacks to me of EJB development, and we're not writing EJBs here,
but I guess I just don't know what you guys mean by "managed" in this
context.
I could write my subclass servlet in straight jdbc + sql, but that would
require duplicating a fair amount of logic that has already been
implemented elsewhere in openJPA.  It would be FAR simpler for me to find
a way to invoke my EXISTING openJPA code but to do it in such a way that
(in the context of this servlet only) it will re-use an existing jdbc
connection and will recognize that there is already a transaction in
progress.




Patrick Linskey <plinskey@...>
07/03/2008 11:34 AM
Please respond to
users@...


To
users@...
cc

Subject
Re: Re-using an existing jdbc connection?






Hi,

What environment are you executing your code in? Is this a Java EE
app? The easiest way is to put a DataSource into JNDI, configure your
transaction manager appropriately, and put OpenJPA into "managed
transaction" mode. In this configuration, the semantics of Connection
delivery will be up to the DataSource implementation.

If you don't have a transaction manager handy, you can create a
DataSource implementation that meets your semantics, and provide it to
OpenJPA when you create your EntityManagerFactory.

-Patrick

On Jul 2, 2008, at 5:39 PM, justin_grunau@... wrote:

> Thanks very much for the joinTransaction() suggestion.
> As for the other suggestion, could you provide more detail on how I
> could
> "make OpenJPA use [the existing JDBC connection] instead of opening
> one on
> its own"? :-)
> Thanks a lot!!
>
>
>
>
>
>
>
>
> Pinaki Poddar <ppoddar@...>
> 07/02/2008 06:35 PM
> Please respond to
> users@...
>
>
> To
> users@...
> cc
>
> Subject
> Re: Re-using an existing jdbc connection?
>
>
>
>
>
>
>
> Hi,
>  If OpenJPA is invoked in a managed transaction context,
> EntityManager.joinTransaction() will make OpenJPA join the existing
> transaction.
>  If there is no managed transaction then you can use a bound the
> existing
> JDBC connection to a thread and make OpenJPA use it instead of
> opening one
> on its own.
>
>
>
> --
> View this message in context:
>
http://n2.nabble.com/Re-using-an-existing-jdbc-connection--tp210696p219975.html

>
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
>

--
Patrick Linskey
202 669 5907


Hiran Chaudhuri
Re: Re-using an existing jdbc connection?
Reply Threaded More
Print post
Permalink
> I have no idea what constitutes a "managed" transaction.  This terminology
> kind of smacks to me of EJB development, and we're not writing EJBs here,
> but I guess I just don't know what you guys mean by "managed" in this
> context.

'Managed' means that someone else manages the transaction, not your code.
So from Tomcat's point of view the transaction is not managed, same for the
base class servlet.
But from your point of view someone else cares for begin and commit, so you
can assume it is managed.