openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey" <plins...@bea.com>
Subject RE: provide an actual JDBC connection?
Date Thu, 26 Apr 2007 16:58:05 GMT
> >
> > Is it possible to provide an actual JDBC connection instead 
> of connect 
> > parameters?
> 
> You can supply the datasource instance in a 
> PersistenceUnitInfo, but I certainly hope you can't provide a 
> connection.

You can also specify a DataSource class name in the
openjpa.ConnectionFactory property; if it has a constructor that lines
up with the arguments you pass in the property value, OpenJPA will
construct it.

> > The business model I'm trying to construct will work inside an 
> > existing application which does direct JDBC. There is already a 
> > connection open and it would be a waste of resource to have 
> two. I can 
> > always hack together a special Driver for this. Another 
> solution would 
> > be to use the connection of OpenJPA.
> 
> Are you running inside a javaee app server?  (not standalone 
> tomcat) If so there's a very good chance that all the 
> connection handles obtained within the same jta transaction 
> actually use the same physical connection to the database.  
> Geronimo certainly does this.

If you just need to get OpenJPA's connection, you can do:

Connection c = (Connection) OpenJPAPersistence.cast(em).getConnection();

Do be careful to close that connection when you're done with it; OpenJPA
does reference-counting on connections to figure out when it's OK to
release connections (see below), and the getConnection() call counts. If
you do transactional work while using the connection, either don't close
the connection until after you call em.getTransaction().commit(), or set
your ConnectionRetainMode to 'transaction' or 'always'. This will ensure
that OpenJPA doesn't throw away the connection that you did your work
on.

> > One concern: how many actual JDBC connections are opened 
> during a run. 
> > I assume that only one is opened and that the JPA "transaction"
> > concept is not
> > directly related to the JDBC transactions. That JDBC 
> transactions are 
> > only used during a JPA transaction's commit phase.

OpenJPA's behavior wrt. connections is controlled by the
openjpa.ConnectionRetainMode property. Briefly, by default, OpenJPA
holds onto connections for as short a time as possible, taking into
account things like flushes and datastore locking.

-Patrick

-- 
Patrick Linskey
BEA Systems, Inc.
_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it. 

> -----Original Message-----
> From: David Jencks [mailto:david_jencks@yahoo.com] 
> Sent: Thursday, April 26, 2007 9:07 AM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: provide an actual JDBC connection?
> 
> 
> On Apr 26, 2007, at 2:10 AM, tbee wrote:
> 
> >
> > Is it possible to provide an actual JDBC connection instead 
> of connect 
> > parameters?
> 
> You can supply the datasource instance in a 
> PersistenceUnitInfo, but I certainly hope you can't provide a 
> connection.
> >
> > The business model I'm trying to construct will work inside an 
> > existing application which does direct JDBC. There is already a 
> > connection open and it would be a waste of resource to have 
> two. I can 
> > always hack together a special Driver for this. Another 
> solution would 
> > be to use the connection of OpenJPA.
> 
> Are you running inside a javaee app server?  (not standalone 
> tomcat) If so there's a very good chance that all the 
> connection handles obtained within the same jta transaction 
> actually use the same physical connection to the database.  
> Geronimo certainly does this.
> >
> > One concern: how many actual JDBC connections are opened 
> during a run. 
> > I assume that only one is opened and that the JPA "transaction"
> > concept is not
> > directly related to the JDBC transactions. That JDBC 
> transactions are 
> > only used during a JPA transaction's commit phase.
> 
> If you use table based "sequences" and supply a 
> non-jta-datasource as  
> well as a jta datasource, typically 2 connections will be used.   
> However, if you are in an environment that does connection 
> pooling this won't make much difference.
> 
> Hope this helps
> david jencks
> 
> 
> > --
> > View this message in context: http://www.nabble.com/provide-an-
> > actual-JDBC-connection--tf3650466.html#a10196861
> > Sent from the open-jpa-dev mailing list archive at Nabble.com.
> >
> 
> 

Notice:  This email message, together with any attachments, may contain information  of  BEA
Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,
 copyrighted  and/or legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient, and have received
this message in error, please immediately return this by email and then delete it.

Mime
View raw message