[jira] [Resolved] (SLING-2786) ResourceMetadata contains stale unmodifiableMap cache after clone()

["Carsten Ziegeler (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SLING-2786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carsten Ziegeler resolved SLING-2786.
-------------------------------------

    Resolution: Fixed

> ResourceMetadata contains stale unmodifiableMap cache after clone()
> -------------------------------------------------------------------
>
>                 Key: SLING-2786
>                 URL: https://issues.apache.org/jira/browse/SLING-2786
>             Project: Sling
>          Issue Type: Bug
>          Components: API
>    Affects Versions: API 2.3.0
>            Reporter: Lukas Eder
>            Assignee: Carsten Ziegeler
>            Priority: Minor
>             Fix For: API 2.5.0
>
>         Attachments: ResourceMetadata.java.clone.patch, ResourceMetadataTest.java.patch
>
>
> Super types of ResourceMetadata (java.util.HashMap and java.util.AbstractMap) correctly implement caching for members such as entrySet, keySet, values, etc. Two things should be considered:
> 1. The cache should be marked transient. It is not desireable to serialise / deserialise the "unmodifiableMap" cache. Only the isReadOnly flag should be serialised
> 2. clone() should be overridden in order to reset the cache on cloned instances
> Consider the following code:
>     	ResourceMetadata map1 = new ResourceMetadata();
>     	map1.put("key1", "value1");
>     	map1.lock();
>     	map1.values(); // Enforce the creation of the cache
>     	ResourceMetadata map2 = (ResourceMetadata) map1.clone();
> Now, map2 contains an unmodifiable wrapper of map1. While this generally behaves correctly, there are two problems:
> a) This is a potential memory leak as clones hold a reference to the original map.
> b) If unlock() is ever added, this might lead to a subtle bug when (after the above code):
>     - map1.unlock() is called
>     - map1 is modified
>     - map2 will reflect map1's modifications, even if map2 should still be locked



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)