This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

I'm trying to implement the OEMIV pattern but am running into problems. I've spent a few days trawling forum posts, but am not much the wiser. Essentially the transaction manager doesn't seem to be aware of the opened session.

I'm using Hibernate as the JPA implementation, and have separate bundles implementing the data model, and the actual vendor specific DAO. I've configured the entitymanager and transaction manager in the Hibernate DAO bundle and exposed them as services thus (only posting relevant bits):

The logs extract below shows an attempt to access the page. OEMIV opens the EntityManager at the start, but when the transaction starts at 16:49:04.859, a new EntityManager is opened, then closed after the transaction, thus leading to the LIE.

Something that looks odd to me happens also at 16:49:08.390 where another raw Hibernate session is opened after the OEMIV filter exits. Should this be happening?

The clues I've picked up from other threads (I can't find them to link to at the moment unfortunately) lead me to suspect it's a class visibility issue, and that the transaction manager may not be seeing the same EntityManagerFactory as the filter. I've tried the Interceptor as well, with the same result.

I'm guessing I've got some configuration issue, but can't for the life of me see what. Any help much appreciated, and if there's anything else I can provide in terms of extra logging output, manifests etc let me know!

Comment

I've come back to this problem as I've got no further tinkering with configurations. I tried to externalise the EntityManagerFactory as suggest in this thread to no avail.

To try to get to the bottom of the problem, I've started to single step through the code for JpaTransactionManager, and OpenEntityManagerInViewFilter and have found what may be a bug.

Both EntityManagerInViewFilter and JpaTransactionManager make use of TransactionSynchronizationManager and use the EntityManagerFactory as a key. Both TransactionSynchronizationManager.bindResource() and TransactionSynchronizationManager.getResource() call TransactionSynchronizationUtils.unwrapResourceIfNe cessary() with the EMF bean (proxies in both cases). That method is shown here:

A sample of what happens is as follows. For OEMIVF, the resource is for example $Proxy283. After calling ((InfrastructureProxy) resourceRef).getWrappedObject() resourceRef is $Proxy270. For JpaTM resource is $Proxy269, and post unwrapping resourceRef is $Proxy270.

This would be wonderful if these were returned at this point, HOWEVER the method trundles on to

Code:

resourceRef = ScopedProxyUnwrapper.unwrapIfNecessary(resource)

which results in resourceRef being trampled by the original resource param, as the bean in question isn't and AOP proxy and thus not unwrapped in the SPU unwrap method.

Is this a bug or a "feature"? If the former, should I raise a JIRA, and if the latter (actually in either case), can anybody suggest a workaround?

Comment

Sigh. To answer my own question it's a bug. It's fixed as of version 3.0.1-RELEASE of the framework, but dm Server 2.0.1 uses 3.0.0-RELEASE, so this is an issue

I've verified by rebuilding 3.0.0-RELEASE with ScopedProxyUnwrapper.unwrapIfNecessary(resource) changed to ScopedProxyUnwrapper.unwrapIfNecessary(resourceRef ) and copying the transaction jar into dm Server repository. At this point OpenEntityManagerInViewFilter will work. I presume the interceptor will work as well, but I'll leave that as an exercise to somebody else.

I also presume the same will apply to anybody using the OpenSessionInView patterns

I'll raise a JIRA for dm Server, and update this post, which might help somebody