[
https://issues.apache.org/jira/browse/LUCENE-3761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shai Erera updated LUCENE-3761:
-------------------------------
Attachment: LUCENE-3761.patch
Option #2:
ThingyManager<G> is an abstract class which implements all the concurrency
administration and exposes the abstract methods tryIncRef(), decRef() and
refreshIfNeeded().
SearcherManager now extends ThingyManager<IndexSearcher> and implements just
these 3 methods (in addition to isSearcherCurrent()).
What I like about this approach is that SearcherManager remains a concrete
class, so that code can reference it and not ThingyManager. Also, IMO it's a
simplified impl vs. the composite ThingyManager/Thingy. AND besides the rename
of maybeReopen to maybeRefresh, NONE of the code was affected by this
refactoring.
I've left the unneeded code as commented out in SearcherManager for easy
comparison, but it should go away. TestSM passes (as well as all core tests),
so I think that ThingyManager handles all concurrency cases as SearcherManager.
However, it could use another inspecting eye :).
As for the name -- now the name is less important b/c I don't think we'll
reference ThingyManagers. I lean towards something like ReferenceManager /
RefCountManager or remove Manager. Something simple. Suggestions are welcome.
> Generalize SearcherManager
> --------------------------
>
> Key: LUCENE-3761
> URL: https://issues.apache.org/jira/browse/LUCENE-3761
> Project: Lucene - Java
> Issue Type: Improvement
> Components: core/search
> Reporter: Shai Erera
> Assignee: Shai Erera
> Priority: Minor
> Fix For: 3.6, 4.0
>
> Attachments: LUCENE-3761.patch, LUCENE-3761.patch
>
>
> I'd like to generalize SearcherManager to a class which can manage instances
> of a certain type of interfaces. The reason is that today SearcherManager
> knows how to handle IndexSearcher instances. I have a SearcherManager which
> manages a pair of IndexSearcher and TaxonomyReader pair.
> Recently, few concurrency bugs were fixed in SearcherManager, and I realized
> that I need to apply them to my version as well. Which led me to think why
> can't we have an SM version which is generic enough so that both my version
> and Lucene's can benefit from?
> The way I see SearcherManager, it can be divided into two parts: (1) the part
> that manages the logic of acquire/release/maybeReopen (i.e., ensureOpen,
> protect from concurrency stuff etc.), and (2) the part which handles
> IndexSearcher, or my SearcherTaxoPair. I'm thinking that if we'll have an
> interface with incRef/decRef/tryIncRef/maybeRefresh, we can make
> SearcherManager a generic class which handles this interface.
> I will post a patch with the initial idea, and we can continue from there.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
