No there are no exceptions. And enabling openjpa.Log Enhance=TRACE did not help either.
But I did some debugging and I could isolate the problem. When I persist my entities I do a flush and a refresh in order to return the entity instance just after the INSERT to the client. This is done because the client does not have to explicitly call a business entity finder method again to get the entity with the now set primary key back. So my persist method does four things: em.persist(myEntity); em.flush(); em.refresh(myEntity); return myEntity; Now it shows that this is the problem. If I remove the flush and refresh calls the "SEVERE: javaAccessorNotSet" errors disappear in my JUnit tests but now I get a stale (meaning the entity has the state BEFORE the INSERT - no primary key is set) entity back. I'm not sure whether this is a good practice because I do a commit in the middle of the business transaction. But the RCP client needs the primary key because after saving the data the client has to execute further business methods which need the primary key. A new remote call to the service facade in order to get the whole entity object tree with all relationships converted to DTOs first, serialized, shipped over the network and then deserialized again is very costly. But maybe you have a nice solution for me? :-) -- View this message in context: http://openjpa.208410.n2.nabble.com/openjpa-Runtime-Unable-to-locate-Transaction-Synchronization-Registry-tp6626607p6632770.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
