Re: openjpa.Runtime Unable to locate Transaction Synchronization Registry
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.
Re: openjpa.Runtime Unable to locate Transaction Synchronization Registry
I don't have a nice solution for you (at least not yet). I may have an explanation for the warning that you're getting. The javaAccessorNotSet can happen if a JNDI namespace is not available. In this case the JPA code is looking for the Transaction Synchronization Registry in JNDI, but it's not available in your unit test environment. For what it's worth, the lookup in question appears to come from the WebSphere JPA provider, not OpenJPA. Since you're using generated primary keys you're going to have to get the value from the database before you can detach the entity. That communication with the database will trigger a JNDI lookup, and this message will be logged. For your unit test you can ignore it (unless you want to set up a JNDI namespace for your unit test). I don't think this helps with your serialization / DTO question, but the error message you're getting seems to be benign. -mike On Fri, Jul 29, 2011 at 3:39 AM, M. Walter marc.wal...@sbb.ch wrote: 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.
Re: openjpa.Runtime Unable to locate Transaction Synchronization Registry
Hi, Is there an exception logged with the message? The inner message is an INFO message, so in itself it should be benign. I'd expect the Transaction Synchronization Registry to only be available in JEE, so I don't think there is anything wrong with your environment. I'm at a loss regarding the javaAccessorNotSet message though. If there is an exception printed, maybe the stack trace will shed some light on the problem. It might also be good to enable trace for OpenJPA.Enhance to make sure the javaagent did enhance your entities. Hope this helps, -mike On Wed, Jul 27, 2011 at 10:39 AM, M. Walter marc.wal...@sbb.ch wrote: Does anyone know what's wrong when this error occurs and how I can fix it? I get this message when I test my EJB DAO with JUnit. I create a new entity and persist it using H2 in-memory database. Next I load the entity from the database again. When I invoke a getter method from the entity the message is printed out. The JUnit test is executed with javaagent runtime enhancement. Here are some loggings: 218 resource-local-pu INFO [main] openjpa.Runtime - Starting OpenJPA 1.2.3-SNAPSHOT 331 resource-local-pu INFO [main] openjpa.jdbc.JDBC - Using dictionary class org.apache.openjpa.jdbc.sql.H2Dictionary. 0 [main] INFO server.persistence.dao.MyDaoBean - Persisting new entity with number [638]. 260 [main] INFO server.persistence.dao.MyDaoBean - Finding entity with primary key [1]. now I invoke entity.getNumber() Jul 27, 2011 5:32:19 PM null null SEVERE: javaAccessorNotSet 4725 resource-local-pu INFO [main] openjpa.Runtime - Unable to locate Transaction Synchronization Registry. -- View this message in context: http://openjpa.208410.n2.nabble.com/openjpa-Runtime-Unable-to-locate-Transaction-Synchronization-Registry-tp6626607p6626607.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
