Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » EclipseLink » EclipseLink migration 2.1.3 -> 2.7.12(An issue with using the refreshIdentityMapResult() method in version 2.7.12)
EclipseLink migration 2.1.3 -> 2.7.12 [message #1859781] Tue, 27 June 2023 07:42
Vladislav Vladislav is currently offline Vladislav VladislavFriend
Messages: 1
Registered: June 2023
Junior Member
Hello community,

Thanks in advance if somebody can help me with tips on solving the below issue by calling the getValue method.

We are using EclipseLink version 2.1.3 and trying to migrate to the latest 2 version (currently in the maven the latest version is 2.7.12).
In our Applications, we are often using the refreshIdentityMapResult() definition in the persistence classes for certain ValueHolder.

During migration to version 2.7.12, I discovered in EclipseLink beginning from version 2.4 the behaviour for the refreshIdentityMapResult() method has been changed.
Now we have side effects for each ValueHolder by using the getValue method for not instantiated objects.

In the Persistence class (Class_1) we have ValueHolder reference (Object_1) as a foreign key to another class (Class_2) and this ValueHolder is configurated
with the refreshIdentityMapResult() function.We read Class_1 and Class_2 from the DB, and do some changes with cloned objects of Class_2.
Class_1 doesn't get any above changes for Class_2 and the problem comes by calling Class_2.getValue from the Class_1 object.
Class_2 in Class_1 at this time wasn't instantiated.

Below is an example of our code:

public class Class_1
public static RelationalDescriptor descriptor()
{
{
RelationalDescriptor d = new RelationalDescriptor();
d.setTableName(Class_1_table);
.
.
OneToOneMapping oneToOneMapping = new OneToOneMapping();
oneToOneMapping.setAttributeName(Object_1);
oneToOneMapping.setReferenceClass(AbstractDomainObject.lookupClass(Class_2));
oneToOneMapping.setForeignKeyFieldName(Object_1_column);
ReadQuery query = oneToOneMapping.getSelectionQuery();
((ReadObjectQuery) query ).refreshIdentityMapResult(); ----> this function set ObjectBuildingQuery.shouldRefreshIdentityMapResult to true in the setShouldRefreshIdentityMapResult
d.addMapping(oneToOneMapping);
.
.
}
}

with EclipseLink 2.14 new behaviour was introduced in the following classes:

UnitOfWorkQueryValueHolder.buildCloneFor -> refreshCascade = ((QueryBasedValueHolder)getWrappedValueHolder()).getRefreshCascadePolicy();

The getRefreshCascadePolicy returns true and then we step in the ObjectReferenceMapping.buildUnitofWorkCloneForPartObject function
with if (refreshCascade != null ) - that is our case due to set refreshIdentityMapResult() for ValueHolder.

Then EclipseLink calls UnitOfWorkImpl.mergeClone with the hardcoded manager.mergeCloneIntoWorkingCopy() where set setMergePolicy to CLONE_INTO_WORKING_COPY.
Then in the MergeManager.mergeChanges we step to mergeChangesOfCloneIntoWorkingCopy(object) function.
Due to this function, our changes in the clone Class_2 are reset. As a result, the DB doesn't update certain columns and we lose all our business logic for most scenarios.

The documentation says the onlyRefreshCacheIfNewerVersion() can be used together with the refreshIdentityMapResult() method but for the above scenario,
EclipseLink doesn't fetch entries from DB, all manipulations happen intern and return the value from the UnitOfWork cache.

I understand that in the above scenario is it possible simply to remove refreshIdentityMapResult() from the ValueHolder definition,
but that is not our case. We have other scenarios where we run multiple Application instances for the JAVA server or can start multiple servers
where we are using multiple threading for the same JAVA server.

In the old version 2.1.3, we go to the mergeChangesOfWorkingCopyIntoOriginal ( default value in the MergeManager constructor {
this.mergePolicy = WORKING_COPY_INTO_ORIGINAL;), not in the mergeChangesOfCloneIntoWorkingCopy.
And now in version 2.7.12 due to hardcoded overwrites merge policy and set setMergePolicy with CLONE_INTO_WORKING_COPY
the getValue method calls mergeChangesOfCloneIntoWorkingCopy.

I have a lot of questions, probably some of you can help me with the above issue:

Is that bug in EclipseLink?
Does EclipseLink offer any possibility for users self-manage MergeManager MergePolicy?
Does it possible avoid to overwriting the default merge policy (WORKING_COPY_INTO_ORIGINAL)?
Does EclipseLink offer any additional configurations that can be managed cache and DB data separately by calling the getValue method?

The setCascadePolicy with all possible cascades didn't give any effect.
I tried the setIsCacheable(true/false) and the setCascadeMerge(true/false), but also without any effect.
Previous Topic:EL 3.0.x not writing into DiscriminatorColumn after migration from 2.7.3
Next Topic:Can't find eclipselink bundle when running java app with docker
Goto Forum:
  


Current Time: Sat Dec 07 09:40:42 GMT 2024

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

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

Back to the top