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