What product/components do you use and which version/fix level?

Integration Server 10.11

Are you using a free trial or a product with a customer license?

Customer License

What are trying to achieve? Please describe in detail.

Does anyone realize on IS 10.11, when a mapped doc reference value changed, the original document that were mapped from also changed it’s value, it’s also happening with pub.cache:get where you suppose to get the value of the cache, when you change the value of the cache, the cache is automatically put with the changed value. Is this a bug on IS 10.11, i think it wasn’t happening on IS 10.7

Have you installed latest fixes for the products

No, i haven’t

Hi there,
this is not a bug, but simply an effect of referenced objects in java. When you copy a document reference to another i.e. say a service call such as pub.cache:put you are not copying the object. So if you make further changes from your reference you are effectively changing the same object in memory. That’s because Object in java are mutable, more and more languages are moving away from mutable Objects to ensure consistency, albeit that itself creates issues because you then have to change quite radically your programming habits, or risk duplicating objects all over the place (bad).

Anyhow if you want to avoid this problem, you can do this by making sure you make a copy of your Object beforehand, with the service pub.utils:deepClone.

Be careful, as I said don’t overuse this technique as it introduces increased memory overhead and a small performance hit.
regards,
John.

Thank you for the advice, i already tried the solution, it worked for me, i just knew this object reference affect the caching memory aswell.

The cache by default is in memory, unless you are using our terracotta product, which uses a hierarchy → memory → local disk → distributed remote cache.
regards,
John.

If you are using Ehcache, in ehcache configuration there is a setting copyOnRead and copyOnWrite. This is also available through Admin UI.

You can set the value to true and it should help to resolve the problem that you are describing.

The “copy by reference” and “copy by value” have always been there. When mapping a doc var, it is copy by reference (not really a copy at all–just another var name for the same object). When mapping strings, it is copy by value. The docs cover this.

As @John_Carter4 points out, this is the same behavior as exists in Java. It’s just that in FLOW it is easier to be led to think mapping a document to another document is copying the entire thing. It does not. But if you map the individual string fields within, you’ll get a copy.

I also concur with @John_Carter4 that deepClone is to be used rarely. IME, copying a doc is relatively rare (I think we have it used in one place–indeed, in the example code I recently shared in “normalizeDocument”). Instead, the more typical case is to map fields from one doc to another because you’re transforming the data to send to another target.