[
https://issues.apache.org/jira/browse/CMIS-432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13108726#comment-13108726
]
Carlo Sciolla commented on CMIS-432:
------------------------------------
Ok, I probably got misled by the *Service name pattern.
I don't fully agree on the last sentence in your comment, as I assume the view
on a given content set might change, with time, even within the scope of the
same user (e.g. because of changed ACLs), or am I completely off track? How is
that local ObjectInfo cache supposed to be used?
> AbstractCmisService is not thread safe
> --------------------------------------
>
> Key: CMIS-432
> URL: https://issues.apache.org/jira/browse/CMIS-432
> 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: http://www.atlassian.com/software/jira
