I'd like to access the persistence layer through JPA/Eclipselink and JDBC Connections in the same application.
The problem is, that changes which have been made directly using the JDBC Connections aren't reflected to the JPA EntityManagers, even though I open the newly created EntityManager afterwards.
I'm using Tomcats JDBC-Connection pool for both, the JDBC Connections and the JPA EntityManagers.
Is there a way to handle such "conflicts"? I've found this: Disable caching in JPA (eclipselink).
I've also found this: http://wiki.eclipse.org/EclipseLink/Examples/JPA/EMAPI#Getting_a_JDBC_Connection_from_an_EntityManager but I don't like the idea, because the code which uses JDBC-Connections is in a seperate library which shouldn't use JPA at all.
Is there a state of the art solution for working likewise with JDBC-Connections and JPA/Eclipselink-Connections?
Have you tried disabling the shared cache? JPA allows two levels of caching - at the factory (shared) level and within the EM itself to hold onto managed entities. If you are making changes outside JPA, you will need to take these caches into account. Using the connection from JPA will not fix this, as it still has no hooks into JPA's caches. So changes outside the EM will only be seen if the em is cleared or the entities involved in the changes are refreshed.
I would use http://wiki.eclipse.org/EclipseLink/Examples/JPA/Caching and the http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Caching link provided by James' answer in the stack overflow question as references.
Using JDBC in the same app is essentially the same as if you were making changes in a different app, except that the JPA application might have more control and knowledge about the changes made, allowing specific invalidation or refreshes to occur. So while disabling the shared cache might be the easiest/quickest solution, EclipseLink invalidation and targeted refreshes might allow still getting the benefits of caching.