[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [eclipselink-users] Sharing EclipseLink Connection with legacy JDBC-code
|
If you are making your own DataSource connection pool, then close() should
return the connection to the pool, and getConnection() should return a
connection from the pool. You should ensure that a connection is never
given to two different threads/transactions/entity managers at the same
time.
patric-7 wrote:
>
> I am acquiring the Connection in plain old Java SE style (own
> connection pool implementation).
> One major question is:
>
> EclipseLink calls at least two times close() on the Connection (at
> instantation of the EntityManager, and on commit()/rollback()).
>
> Is it safe to wrap the real connection in a proxy object, just ignore
> the close() and always return the same Connection by the DataSource
> which is used within the EclipeLink session?
>
> Patric
>
> Zitat von Tim Hollosy <hollosyt@xxxxxxxxx>:
>
>> It would depend on how you're getting your connection. For example, I
>> know in spring you can share a Datasource with no problem as long as
>> the same Spring Transaction Manager manages the EntityManagerFactory
>> and the datasource.
>>
>> ./tch
>>
>>
>>
>> On Mon, Aug 16, 2010 at 10:17 AM, <patric@xxxxxxxxxx> wrote:
>>>
>>> Hello everyone,
>>>
>>> is it possible to share an EclipseLink Connection with a regular JDBC
>>> Connection?
>>>
>>> Imagine an application which consists of several JDBC queries/statements
>>> inside one transaction.
>>> I'd like to do some refactoring and replace some old JDBC code with JPA
>>> using EclipseLink.
>>>
>>> Is it possible that EclipseLink is using the same Connection as the
>>> legacy
>>> JDBC code, so that it "sees" the uncommited data which have been made
>>> before
>>> and that regular JDBC which will be executed afterwards can see the
>>> changed
>>> data for EclipseLink?
>>>
>>> (of course, the I have to call flush() the entitymanager)
>>>
>>> If it's not possible - what would you suggest for such a refactoring?
>>>
>>> Thank you!
>>>
>>> Best regards,
>>> Patric
>>>
>>>
>>> _______________________________________________
>>> eclipselink-users mailing list
>>> eclipselink-users@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>>>
>> _______________________________________________
>> eclipselink-users mailing list
>> eclipselink-users@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>>
>
>
>
>
> _______________________________________________
> eclipselink-users mailing list
> eclipselink-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>
>
-----
http://wiki.eclipse.org/User:James.sutherland.oracle.com James Sutherland
http://www.eclipse.org/eclipselink/
EclipseLink , http://www.oracle.com/technology/products/ias/toplink/
TopLink
Wiki: http://wiki.eclipse.org/EclipseLink EclipseLink ,
http://wiki.oracle.com/page/TopLink TopLink
Forums: http://forums.oracle.com/forums/forum.jspa?forumID=48 TopLink ,
http://www.nabble.com/EclipseLink-f26430.html EclipseLink
Book: http://en.wikibooks.org/wiki/Java_Persistence Java Persistence
--
View this message in context: http://old.nabble.com/Sharing-EclipseLink-Connection-with-legacy-JDBC-code-tp29450647p29522764.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.