UnitOfWork throws NPE on calling commitAndResumeOnFailure()

[eclipse-ee4j]

UnitOfWork throws NPE on calling commitAndResumeOnFailure()

[dazey3]

If you have a simple test that reproduces the failure, perhaps you can provide that to demonstrate the issue?

Also, interesting that AbstractSession.accessors has a null value in it. I would investigate where that null is coming from more closely if you have a debugger setup.

[nairanups]

Hi @dazey3,
Though we don't have test to demonstrate, we can replicate the scenario through UI.
I have attached the eclipselink sources jar in debug session. Please let me know if we can have a debug session.

[nairanups]

Hi @dazey3 ,
Our migration from TopLink to EclipseLink was followed based on the migration guide provided here. As our existing project on TopLink was based on native SQL through session.xml configuration and not by JPA, we retained the same approach and didn't introduce JPA or the persistence.xml based configuration. We are using Oracle 11g and TomEE Plus 1.7.3 (Not Tomee Plume) as our database and app server respectively.

Our datasource resources are configured in tomee.xml. During TomEE startup, the sessions.xml file is picked up by a bean present in the spring configuration file global-context.xml. The sessions xml sample shows our primary-project configuration mapped to a class where we perform the domain object mappings. The login and descriptors of all related tables are configured in this class. The properties of the descriptors like native sequencing, identity map (soft cache weak) are prepared as prescribed in the migration guide document.

Our application follows a struts MVC structure, wherein the requests are served by the action classes. Within the action class we invoke a service class that handles the database transactions. In a typical scenario, we acquire the UoW from the client session (configured as database-session). The unit of work is then registered with appropriate object on which we intend to perform a database transaction.

While the above configuration and steps have worked for almost every scenario, in a particular case we set the acquired UoW in a value object and store the value object in the app request / response session. This is carried out to keep the state of an operation (booking a ticket, in our case) locked and maintain the versions. As there could be multiple changes to the operation keeping the UoW and writing back every version of the changed object is followed consistently. The issue we noticed appears when we try to get the UoW from the value object and perform commitAndResumeOnFailure(). Upon commit, the accessors of the session returns null. [snapshot of the uow object]. This in particular is very strange when we compared with TopLink. Just like TopLink, EclipseLink UoW also creates the UoW with its parent being Client Session. The difference however is that both the client session and server session of TopLink hold database accessor while only the server session of EclipseLink hold the database accessor. We replicated this with our other working scenarios and the accessor of client session was null in that case as well.

Alternatively, we acquired a new uow and registered the domain object again instead of using the existing uow from the session. This worked for us and could see the cloneMapping / cloneToOriginal property of uow drastically differ between the uow picked from the session and the newly acquired uow. The newly acquired uow had the clone of all the objects that were added as descriptors while the uow from the session held only few objects.

Any help on the issue with existing UoW in session will be highly appreciated.