Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » EclipseLink » Toplink to Eclipselink migration(java.lang.NullPointerException at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.insertObject(DatasourceCallQueryMechanism.java:429))
Toplink to Eclipselink migration [message #1792857] Wed, 25 July 2018 08:28 Go to next message
Rohan Rele is currently offline Rohan ReleFriend
Messages: 7
Registered: July 2018
Junior Member
We are doing migration from Toplink to Eclipselink (native api) for a big application.

We have never worked on Eclipselink before. We have worked on Hibernate. We are using Eclipselink 2.7.2 with Java 8. In some scenarios when commitAndResumeOnFailure() is called on unit of work the below exception is thrown:

java.lang.NullPointerException
Message: null
-----
org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.insertObject(DatasourceCallQueryMechanism.java:432)
org.eclipse.persistence.internal.queries.StatementQueryMechanism.insertObject(StatementQueryMechanism.java:165)
org.eclipse.persistence.internal.queries.StatementQueryMechanism.insertObject(StatementQueryMechanism.java:180)
org.eclipse.persistence.internal.queries.DatabaseQueryMechanism.insertObjectForWrite(DatabaseQueryMechanism.java:502)
org.eclipse.persistence.queries.InsertObjectQuery.executeCommit(InsertObjectQuery.java:80)
org.eclipse.persistence.queries.InsertObjectQuery.executeCommitWithChangeSet(InsertObjectQuery.java:90)
org.eclipse.persistence.internal.queries.DatabaseQueryMechanism.executeWriteWithChangeSet(DatabaseQueryMechanism.java:314)
org.eclipse.persistence.queries.WriteObjectQuery.executeDatabaseQuery(WriteObjectQuery.java:58)
org.eclipse.persistence.queries.DatabaseQuery.execute(DatabaseQuery.java:911)
org.eclipse.persistence.queries.DatabaseQuery.executeInUnitOfWork(DatabaseQuery.java:810)
org.eclipse.persistence.queries.ObjectLevelModifyQuery.executeInUnitOfWorkObjectLevelModifyQuery(ObjectLevelModifyQuery.java:108)
org.eclipse.persistence.queries.ObjectLevelModifyQuery.executeInUnitOfWork(ObjectLevelModifyQuery.java:85)
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.internalExecuteQuery(UnitOfWorkImpl.java:2979)
org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1892)
org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1874)
org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1824)
org.eclipse.persistence.internal.sessions.CommitManager.commitNewObjectsForClassWithChangeSet(CommitManager.java:227)
org.eclipse.persistence.internal.sessions.CommitManager.commitAllObjectsForClassWithChangeSet(CommitManager.java:194)
org.eclipse.persistence.internal.sessions.CommitManager.commitAllObjectsWithChangeSet(CommitManager.java:139)
org.eclipse.persistence.internal.sessions.AbstractSession.writeAllObjectsWithChangeSet(AbstractSession.java:4384)
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitToDatabase(UnitOfWorkImpl.java:1491)
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitToDatabaseWithChangeSet(UnitOfWorkImpl.java:1581)
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitRootUnitOfWork(UnitOfWorkImpl.java:1401)
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitAndResume(UnitOfWorkImpl.java:1218)
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitAndResumeOnFailure(UnitOfWorkImpl.java:1297)

Could someone please help?
Re: Toplink to Eclipselink migration [message #1793005 is a reply to message #1792857] Fri, 27 July 2018 12:12 Go to previous messageGo to next message
Lukas JungmannFriend
Messages: 30
Registered: November 2013
Location: Prague, Czech Republic
Member
What does it mean 'some scenario'? Can you define it?

thanks,
Re: Toplink to Eclipselink migration [message #1793452 is a reply to message #1793005] Wed, 08 August 2018 15:11 Go to previous messageGo to next message
Rohan Rele is currently offline Rohan ReleFriend
Messages: 7
Registered: July 2018
Junior Member
Hi @dazey3 ,
Our migration from TopLink to EclipseLink was followed based on the migration guide provided [here]( http://www.eclipse.org/eclipselink/documentation/2.7/solutions/migrnativetoplink001.htm#BCGGFGDG). As our existing project on TopLink was based on native SQL through [session.xml](https://gist.github.com/nairanups/ee26d72a40c81ed7d3edd56430c5c288#file-sessions-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](https://gist.github.com/nairanups/ee26d72a40c81ed7d3edd56430c5c288#file-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](https://gist.github.com/nairanups/ee26d72a40c81ed7d3edd56430c5c288#file-tlresrlogin-java) 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](https://gist.github.com/nairanups/ee26d72a40c81ed7d3edd56430c5c288#file-tlrervbooking-java) 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.
Re: Toplink to Eclipselink migration [message #1793453 is a reply to message #1793005] Wed, 08 August 2018 15:12 Go to previous messageGo to next message
Rohan Rele is currently offline Rohan ReleFriend
Messages: 7
Registered: July 2018
Junior Member
Hi @dazey3 ,
Our migration from TopLink to EclipseLink was followed based on the migration guide provided [here]( http://www.eclipse.org/eclipselink/documentation/2.7/solutions/migrnativetoplink001.htm#BCGGFGDG). As our existing project on TopLink was based on native SQL through [session.xml](https://gist.github.com/nairanups/ee26d72a40c81ed7d3edd56430c5c288#file-sessions-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](https://gist.github.com/nairanups/ee26d72a40c81ed7d3edd56430c5c288#file-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](https://gist.github.com/nairanups/ee26d72a40c81ed7d3edd56430c5c288#file-tlresrlogin-java) 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](https://gist.github.com/nairanups/ee26d72a40c81ed7d3edd56430c5c288#file-tlrervbooking-java) 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.
Re: Toplink to Eclipselink migration [message #1793975 is a reply to message #1793453] Tue, 21 August 2018 13:10 Go to previous messageGo to next message
Rohan Rele is currently offline Rohan ReleFriend
Messages: 7
Registered: July 2018
Junior Member
Hi @Lukas,

While debugging, we strangely observed that on calling the UnitOfWork.commitAndResumeOnFailure(), if i step into the eclipselink source code and iterate through each of the object change sets, it successfully commits the registered objects within UoW to database. However if i step over the UnitOfWork.commitAndResumeOnFailure(), it gives me NPE on org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.insertObject(DatasourceCallQueryMechanism.java:432).

We are using SoftCacheWeakIdentityMap for descriptors.

Does this have anything to do with synchronization or lock?

Do we need to change our identity map class for descriptors?

Please help.
Re: Toplink to Eclipselink migration [message #1795874 is a reply to message #1793975] Mon, 01 October 2018 15:18 Go to previous message
Chris Delahunt is currently offline Chris DelahuntFriend
Messages: 1305
Registered: July 2009
Senior Member
Odd issue, and the line number doesn't exactly match up with what I have locally or is in GitHub, so it is difficult to say for sure what is or could be null.

In another thread, you seem to mention this is due to accessors being null. From the description and the fact it won't reproduce in a debugger, it suggest it is a concurrent access issue. This could only occur if you are concurrently using a UnitOfWork in multiple threads. These instances, and the objects read from them, are not thread safe. For instance, closing a UnitOfWork while another thread is using it might cause this issue.

If you have a debugger open, while it may not reproduce the issue, you may be able to check which threads are using that executionSession, its type, and the list of accessors.
Previous Topic:Behaviour of changed data read by ClientSession
Next Topic:UnitOfWork parent(ClientSession) turns inActive
Goto Forum:
  


Current Time: Fri Nov 16 11:21:30 GMT 2018

Powered by FUDForum. Page generated in 0.02252 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top