[jira] Commented: (DERBY-4210) Use a shared pool for background threads (rawStoreDaemon)

["Kathey Marsden (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DERBY-4210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705621#action_12705621 ] 

Kathey Marsden commented on DERBY-4210:
---------------------------------------

This would conflict with my idea for solving DERBY-700 to prevent dual boot from different ClassLoaders by putting the database name in the thread name and checking for existence of the  relevant thread before starting up a new one.

I think though that I will go ahead and pursue my idea for DERBY-700 or at least prototype it as it seems to be the only promising option for resolving that critical issue.  Then whoever pursues this issue can look into some other way to prevent regression if DERBY-700 has been  fixed that way.


> Use a shared pool for background threads (rawStoreDaemon)
> ---------------------------------------------------------
>
>                 Key: DERBY-4210
>                 URL: https://issues.apache.org/jira/browse/DERBY-4210
>             Project: Derby
>          Issue Type: Improvement
>          Components: Store
>    Affects Versions: 10.5.1.1
>            Reporter: Arnaud Masson
>
> Use a shared pool for background threads (rawStoreDaemon).
> May it could be a configuration option (pooling or not, max pool size, core pool size, ...).
> I have an application that opens several small derby databases (using EmbeddedDriver).
> Most of these instances don't handle many requests, but each instance maintains its own thread "derby.rawStoreDaemon".
> It would more efficient to use a thread pool shared by all the instances.
> See http://osdir.com/ml/apache.db.derby.devel/2005-04/msg00093.html
> See also DERBY-206 and DERBY-696 about threading in Derby.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.