[
https://issues.apache.org/jira/browse/LUCENE-3761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13206909#comment-13206909
]
Shai Erera commented on LUCENE-3761:
------------------------------------
Thanks for the education guys. Simon's example clarified my confusion -- if all
access to a variable are synchronized, it doesn't need to be volatile. However
in ThingyManager, only setting the variable is synced, but reading it isn't.
That's why it needs to be volatile. And swapThingy needs to be synced for
concurrency issues (close in parallel to maybeRefresh).
I will declare it volatile. Will upload a patch soon.
BTW, I'd like to rename maybeRefresh to refresh() because this method doesn't
return an instance or anything, and to me it's just like calling refresh on say
a web page - nothing guarantees that it will change. The method returns
true/false depending on whether refresh was done. Are there any objections?
> 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
