> > > > 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:[EMAIL PROTECTED] > 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.
