chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Florent Guillaume (JIRA)" <>
Subject [jira] Resolved: (CMIS-103) APPConnection Thread Safety
Date Wed, 10 Feb 2010 16:37:28 GMT


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


> APPConnection Thread Safety
> ---------------------------
>                 Key: CMIS-103
>                 URL:
>             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.

View raw message