Skip to main content

[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.



Back to the top