Mailing-List: contact chemistry-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: chemistry-dev@incubator.apache.org
Message-ID: <1128685799.182761265819848112.JavaMail.jira@brutus.apache.org>
Date: Wed, 10 Feb 2010 16:37:28 +0000 (UTC)
From: "Florent Guillaume (JIRA)" <jira@apache.org>
To: chemistry-dev@incubator.apache.org
Subject: [jira] Resolved: (CMIS-103) APPConnection Thread Safety
In-Reply-To: <496377506.57621264566995516.JavaMail.jira@brutus.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ 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.