|
|
| Re: Toplink to Eclipselink migration [message #1793452 is a reply to message #1793005] |
Wed, 08 August 2018 15:11   |
 Rohan Rele
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 |
Rohan Rele
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 #1795874 is a reply to message #1793975] |
Mon, 01 October 2018 15:18 |
Chris Delahunt
Messages: 1389
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.
|
|
|
Powered by
FUDForum. Page generated in 0.03300 seconds
] 
Search
Help
Register
Login
Home
