|
|
Re: refreshObject after commit causes problem for value change in the next transaction [message #1753482 is a reply to message #1752917] |
Tue, 07 February 2017 00:43 |
Chris Delahunt Messages: 1389 Registered: July 2009 |
Senior Member |
|
|
I haven't seen the native API used in a while, so I'm not quite sure the setting you might use to change the behavior, but the issue is to be expected. Setting private ownership in native EclipseLink api would cause the equivalent of JPA's cascade options over the relationship when using the native api methods, such as refreshObject on the client session. This means that when refreshing the object, the indirection is reset and when triggered, refreshes the referenced object as you've seen.
The problem here is that you are using refreshObject on the ClientSession, a convenience method for:
public Object refreshAndLockObject(Object object, short lockMode) throws DatabaseException {
ReadObjectQuery query = new ReadObjectQuery();
query.setSelectionObject(object);
query.refreshIdentityMapResult();
query.cascadePrivateParts();
query.setLockMode(lockMode);
query.setIsExecutionClone(true);
return executeQuery(query);
}
The problem is with the cascadePrivateParts() setting. You will want to create an execute your own query leaving that part out, or calling dontCascadeParts() on it to prevent the refresh from cascading to privately owned references when the indirection is triggered.
An alternative solution is to trigger the reference upfront, by calling getQuestions(); immediately after the refresh.
Best Regards,
Chris
|
|
|
|
Powered by
FUDForum. Page generated in 0.02191 seconds