chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Florian Müller (JIRA) <>
Subject [jira] [Commented] (CMIS-432) AbstractCmisService is not thread safe
Date Tue, 20 Sep 2011 14:34:08 GMT


Florian Müller commented on CMIS-432:

The object infos are only collected for one call and the map is recreated for each request.
The info objects are not kept across multiple calls or for a longer period of time. (At least,
that is default implementation. Repositories may choose to override this behavior and implement
their own caching policy. But since this is very repository specific, the framework cannot
provide much support here.) 

The object infos are required to build spec compliant AtomPub responses. The data is requested
multiple times from different parts of the framework when the Atom XML is generated. Since
building info objects can be expensive, they are kept and don't have to be recreated whenever
the framework requires a piece of information.

> AbstractCmisService is not thread safe
> --------------------------------------
>                 Key: CMIS-432
>                 URL:
>             Project: Chemistry
>          Issue Type: Improvement
>          Components: opencmis-commons
>    Affects Versions: OpenCMIS 0.5.0
>            Reporter: Carlo Sciolla
>              Labels: concurrency, multithread, thread-safety
> The use of an unsynchronized HashMap for storing AbstractCmisService.objectInfoMap (see
AbstractCmisService.getObjectInfoMap) makes it inherently thread unsafe. When extending that
class, we ran in busy waits on HashMap.get, which we fixed overriding the following two methods
to which we added the {{syncronized}} bit:
> {code:java}
>     @Override
>     public synchronized ObjectInfo getObjectInfo(String repositoryId, String objectId)
>         return super.getObjectInfo(repositoryId, objectId);
>     }
>     @Override
>     public synchronized void addObjectInfo(ObjectInfo objectInfo) {
>         super.addObjectInfo(objectInfo);
>     }
> {code}
> It would still be nice if thread safety is provided by the library itself without the
need for external synchronization.

This message is automatically generated by JIRA.
For more information on JIRA, see:


View raw message