Please see my comments below > Currently you have to make a copy of BinaryObject for each cache operation > because it's not immutable and internally caches some information for > performance reasons.
Isn't the BinaryObject not bound <http://apache-ignite-users.70518.x6.nabble.com/Ignite-client-reads-old-metadata-even-after-cache-is-destroyed-and-recreated-tp5800p5823.html> to any cache? Also note that adding the same binary object to two caches works if the synchronization mode of the replicated cache is PRIMARY_SYNC and not FULL_SYNC. Why would this be working? > Do you have a real case then you need to put a lot of binary object keys > to multiple caches? I was trying to simulate a workaround for the IGNITE-1897 <https://issues.apache.org/jira/browse/IGNITE-1897> where I maintain a replicated cache for all the entries that are added/updated in a transaction. Hence I am adding the same key/value pair to two caches. > BTW, if you are using BinaryObject key with only single standard java type > it's simpler to just use the type as a cache key. No I do have multiple fields as part of the BinaryObject. Its just for reproducing the issue I added one field -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Adding-a-binary-object-to-two-caches-fails-with-FULL-SYNC-write-mode-configured-for-the-replicated-ce-tp6343p6366.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.
