[
https://issues.apache.org/jira/browse/CMIS-432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13108767#comment-13108767
]
Carlo Sciolla commented on CMIS-432:
------------------------------------
Thanks for the link, I guess I overlooked this part:
bq.The getService method must return an object that implements the CmisService
interface. This object will only be used in this thread. When the object is not
needed anymore, the close method on the object will be called.
I would change "will" to "must" wherever appropriate, e.g.: how strict should
implementors be in calling close()?
Indeed, that's definitely another topic. Feel free to close this issue.
> 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
