Re: provide an actual JDBC connection?
Marina Vatkina wrote: > > Can you pass a connection from em to the other side instead? > That would be an option tool using EM as a pool. I have to experiment with OpenJPA connection behaviour a bit. -- View this message in context: http://www.nabble.com/provide-an-actual-JDBC-connection--tf3650466.html#a10213595 Sent from the open-jpa-dev mailing list archive at Nabble.com.
Re: provide an actual JDBC connection?
Can you pass a connection from em to the other side instead? tbee wrote: djencks wrote: You can supply the datasource instance in a PersistenceUnitInfo, but I certainly hope you can't provide a connection. 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. No, stand alone fat client. And I could hackup a datasource instead.
RE: provide an actual JDBC connection?
I would say check to docs then. I think you can get at the driver directly but I am not sure of your ability to supply one in flight through JPA -Original Message- From: tbee [mailto:[EMAIL PROTECTED] Sent: April 26, 2007 9:56 AM To: open-jpa-dev@incubator.apache.org Subject: RE: provide an actual JDBC connection? Phill Moran wrote: > > Have you tried to use Spring? I think you may be able to get that with > dependency injection. Not positive but thought I would throw in that > suggestion > You really want to give me a heart attack? ;-) I'm not a spring fan. -- View this message in context: http://www.nabble.com/provide-an-actual-JDBC-connection--tf3650466.html#a1020086 9 Sent from the open-jpa-dev mailing list archive at Nabble.com.
RE: provide an actual JDBC connection?
> > > > 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 > > > > -- >
Re: provide an actual JDBC connection?
djencks wrote: > > You can supply the datasource instance in a PersistenceUnitInfo, but > I certainly hope you can't provide a connection. > > 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. > No, stand alone fat client. And I could hackup a datasource instead. -- View this message in context: http://www.nabble.com/provide-an-actual-JDBC-connection--tf3650466.html#a10204809 Sent from the open-jpa-dev mailing list archive at Nabble.com.
RE: provide an actual JDBC connection?
You can't provide a JDBC connection directly, but you can provide a DataSource, which, in turn, can provide a connection. -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: tbee [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 26, 2007 2:10 AM > To: open-jpa-dev@incubator.apache.org > Subject: provide an actual JDBC connection? > > > Is it possible to provide an actual JDBC connection instead > of connect parameters? > > 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. > > 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. > -- > View this message in context: > http://www.nabble.com/provide-an-actual-JDBC-connection--tf365 0466.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.
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.
RE: provide an actual JDBC connection?
Phill Moran wrote: > > Have you tried to use Spring? I think you may be able to get that with > dependency injection. Not positive but thought I would throw in that > suggestion > You really want to give me a heart attack? ;-) I'm not a spring fan. -- View this message in context: http://www.nabble.com/provide-an-actual-JDBC-connection--tf3650466.html#a10200869 Sent from the open-jpa-dev mailing list archive at Nabble.com.
RE: provide an actual JDBC connection?
Have you tried to use Spring? I think you may be able to get that with dependency injection. Not positive but thought I would throw in that suggestion -Original Message- From: tbee [mailto:[EMAIL PROTECTED] Sent: April 26, 2007 5:10 AM To: open-jpa-dev@incubator.apache.org Subject: provide an actual JDBC connection? Is it possible to provide an actual JDBC connection instead of connect parameters? 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. 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. -- View this message in context: http://www.nabble.com/provide-an-actual-JDBC-connection--tf3650466.html#a1019686 1 Sent from the open-jpa-dev mailing list archive at Nabble.com.
