From derby-user-return-10938-apmail-db-derby-user-archive=db.apache.org@db.apache.org Mon May 04 13:04:59 2009 Return-Path: Delivered-To: apmail-db-derby-user-archive@www.apache.org Received: (qmail 52031 invoked from network); 4 May 2009 13:04:59 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 4 May 2009 13:04:59 -0000 Received: (qmail 90379 invoked by uid 500); 4 May 2009 13:04:58 -0000 Delivered-To: apmail-db-derby-user-archive@db.apache.org Received: (qmail 90311 invoked by uid 500); 4 May 2009 13:04:58 -0000 Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Reply-To: "Derby Discussion" Delivered-To: mailing list derby-user@db.apache.org Received: (qmail 90303 invoked by uid 99); 4 May 2009 13:04:58 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 May 2009 13:04:58 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of amasson@gmail.com designates 209.85.219.211 as permitted sender) Received: from [209.85.219.211] (HELO mail-ew0-f211.google.com) (209.85.219.211) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 May 2009 13:04:49 +0000 Received: by ewy7 with SMTP id 7so4464864ewy.7 for ; Mon, 04 May 2009 06:04:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=ycG1udkll8tAlDkCPqGIAX/feuwgQ65gZsX+JN+68Do=; b=Fe5WYbiCUHqtaNMAWDvJ97t6LO7Ht6myaSq2eveX2l3sIievuhRsSBpxeFEnT7tMqU KWqfoxxu8dF6DMON/j6LasIF+5YgKFuh4cquPLvS5wyxIMwHMM5h5CYB421V0wbGXJJ7 tSaXeqEKs1+3N5Y+nBMWWopsAIrRR0MlD6DvU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=HeGdPMI90WXyrtbQQ6gY/ztVteYgEtr6HJibUuPOa1g8vv4rMzRcKzrXHZj3dgS3iY 4NMl6zGE8taHbAw3FtHQtUUHkf+gnsueY/cM7lrwN86PVi+mhC75IU8LD96C0KrsNR/R ZaL4XBgnEDb9rWzXA/MdyD7NEXsTdtPKfbbX8= Received: by 10.210.20.17 with SMTP id 17mr1767146ebt.84.1241442267279; Mon, 04 May 2009 06:04:27 -0700 (PDT) Received: from ?10.70.10.131? (4be54-2-82-224-84-95.fbx.proxad.net [82.224.84.95]) by mx.google.com with ESMTPS id 23sm1930842eya.59.2009.05.04.06.04.25 (version=SSLv3 cipher=RC4-MD5); Mon, 04 May 2009 06:04:26 -0700 (PDT) Message-ID: <49FEE7D8.5050401@gmail.com> Date: Mon, 04 May 2009 15:04:24 +0200 From: Arnaud Masson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Derby Discussion Subject: Re: Many background threads (rawStoreDaemon) References: <20090504121854.6D6CE5DBD2@dbrack01.segel.com> In-Reply-To: <20090504121854.6D6CE5DBD2@dbrack01.segel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org derby@segel.com a écrit : > >> -----Original Message----- >> >>>> I have an application that opens several small derby databases (using >>>> EmbeddedDriver). >>>> Most of of these instances don't handle many requests. >>>> The problem is that each instance maintain its own thread >>>> "derby.rawStoreDaemon". >>>> Is there a way to use a thread pool shared between instances instead ? >>>> (There is also a discussion about that here: >>>> http://osdir.com/ml/apache.db.derby.devel/2005-04/msg00093.html) >>>> >>> I am not aware any progress has been made on this issue, unfortunately. >>> >> If you think it should be adressed, filing a JIRA issue is a good first >> step: https://issues.apache.org/jira/browse/DERBY >> >> (I don't think there is one filed yet, is it?) >> > > Ok so if I understand this... > > A person wants to open multiple embedded copies of a database and then > thread pool the database server connections/controllers of the individual > database connections. > > Ok, yes there is some merit to this. Unfortunately, you're adding a lot of > weight to the code that means a larger footprint making it harder to embed. > > This is not about connection pool. This is about the fact that each derby instance maintain a thread that is sleeping most of the time (rawStoreDaemon). It would be better for the footprint to free daemon threads when they are not used or to recycle them in a pool (like JDK Executor).