Return-Path: X-Original-To: apmail-camel-users-archive@www.apache.org Delivered-To: apmail-camel-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 3197411FD4 for ; Wed, 4 Jun 2014 01:39:49 +0000 (UTC) Received: (qmail 95308 invoked by uid 500); 4 Jun 2014 01:39:48 -0000 Delivered-To: apmail-camel-users-archive@camel.apache.org Received: (qmail 95267 invoked by uid 500); 4 Jun 2014 01:39:48 -0000 Mailing-List: contact users-help@camel.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@camel.apache.org Delivered-To: mailing list users@camel.apache.org Received: (qmail 95256 invoked by uid 99); 4 Jun 2014 01:39:48 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Jun 2014 01:39:48 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of christian.posta@gmail.com designates 209.85.215.47 as permitted sender) Received: from [209.85.215.47] (HELO mail-la0-f47.google.com) (209.85.215.47) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Jun 2014 01:39:45 +0000 Received: by mail-la0-f47.google.com with SMTP id pn19so3952162lab.20 for ; Tue, 03 Jun 2014 18:39:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=TXkaQ97qkk7oXadtFnUQhysxQDU8UOJFhj29giW8wmI=; b=Tr86a15ouJ8cLL7Pazt/YULubRDUYqmDp43N8v9wnjBCW5TPn4tdlSPjh6zw43Ar0g XQg42niiDyU1bIVSN1SGypTk/EQ8fVN2Gz/AObiRPEXf8Y4cOTtEYAO4v93fWapY/3uB SfTWofMFsyUmfviUUtHu3S4aPWPGV0PniyArOBW6j491xIo1bRxWERGwtTV941apuQle reMvcZiDOhkg3ma1bX9L7TpDhj8ULumQ/lufMcfpT35JjQNzfFmINg9qc0d335Ad4VJD PDIGL4Y+gHFeIcTwToZ9WAf1/oWVDNkYorf/owOKJk9hUpFPDpYPMa08rEOMfF62av6g TcFA== MIME-Version: 1.0 X-Received: by 10.112.143.98 with SMTP id sd2mr34628399lbb.15.1401845962320; Tue, 03 Jun 2014 18:39:22 -0700 (PDT) Received: by 10.112.150.225 with HTTP; Tue, 3 Jun 2014 18:39:22 -0700 (PDT) In-Reply-To: References: Date: Tue, 3 Jun 2014 18:39:22 -0700 Message-ID: Subject: Re: Questions regarding Camel file2 component From: Christian Posta To: "users@camel.apache.org" Content-Type: multipart/alternative; boundary=089e0115fb1a9d32de04faf8b2da X-Virus-Checked: Checked by ClamAV on apache.org --089e0115fb1a9d32de04faf8b2da Content-Type: text/plain; charset=UTF-8 Depends on what your routes look like to accomplish this. The synchronization doesn't happen at the CamelContext per se but at the file-system level. So if you have multiple threads contending for the files in the same directory (whether in same camelcontext or not), then you'll have to use a readLock strategy that supports your use case: http://camel.apache.org/file2.html On Tue, Jun 3, 2014 at 1:45 PM, Pascal Klink wrote: > > > Hi everyone, > > I have a question regarding the file2 component of Apache Camel. I'm > currently trying to write a small application with which pictures can be > stored and retrieved. I'm organizing the pictures in folders - one for > every user. Since all users can look at the pictures from other users, > there will be concurrent read/write operations on the various pictures. > > My question is, is Camel snychronizing those read/write operations for one > CamelContext? The application will be a WebService, so the reads and writes > will happen in different threads but one CamelContext. A read/write lock > behaviour (with multiple concurrent readers but only one writer) would be > ideal for this. So I'm very interested whether this is possible with the > file2 component? > > Greetings, > Pascal > -- *Christian Posta* http://www.christianposta.com/blog twitter: @christianposta --089e0115fb1a9d32de04faf8b2da--