[
https://issues.apache.org/jira/browse/CMIS-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florent Guillaume resolved CMIS-103.
------------------------------------
Resolution: Fixed
Thanks for the patch.
MultiThreadedHttpConnectionManager was there from earlier tests but was not
actually needed anymore in non-multi-threaded usage. But its use is good yes.
I simplified a bit the credentials code.
I made SimpleTypeManager thread-safe using a ReentrantReadWriteLock which is
more efficient than using the java.util.concurrent collections (and there is no
concurrent LinkedHashMap anyway).
r908573
> APPConnection Thread Safety
> ---------------------------
>
> Key: CMIS-103
> URL: https://issues.apache.org/jira/browse/CMIS-103
> Project: Chemistry
> Issue Type: Bug
> Components: atompub
> Reporter: Chris Hubick
> Attachments: chemistry_connection_thread_safety.patch
>
>
> Hi.
> It would be really great if APPConnection were thread safe, at least for
> reading.
> When my server application starts up, I would like to create an instance of
> APPContentManager, login, etc, and then get a reference to the default
> Repository object. My application would then service client requests, each
> running in a separate Thread which calls Repository.getConnection() to get
> it's own Connection (APPConnection) for reading from the backend Repository.
> A persistent and shared Repository means that each of many service Thread's
> doesn't require a separate HTTP request to download the CMIS Service
> Document, and then overhead due to parsing, type management, etc.
> From a first glance, the main problem is that the HttpClient instance is
> shared among all APPContentManager clients, and APPRespository doesn't
> synchronize calls to loadTypes().
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
