lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <markrmil...@gmail.com>
Subject Re: [jira] Commented: (LUCENE-1026) Provide a simple way to concurrently access a Lucene index from multiple threads
Date Thu, 29 Nov 2007 19:41:32 GMT
I've been thinking about this and I think the situation we are in is 
okay. The variable is an int and so should be read in one memory access 
(i would think?). So at worst, the result might be stale? Since this 
read is just for informational type purposes, (eg its ok if this 
particular method returns a stale value, by the time you read it its 
likely to have changed anyway), I think its okay.

I think. Everything I read about the Java memory model, I quickly forget.

robert engels wrote:
> FYI, any time one thread reads a value while another thread updates it 
> it needs to be synchronized, or with current JVMs a volatile variable.
>
> The Java Memory Model requires this.
>
> Otherwise you can get a partial value (when the underlying value 
> requires more than one memory access to retrieve).
>
> On Nov 29, 2007, at 6:43 AM, Mark Miller (JIRA) wrote:
>
>>
>>     [ 
>> https://issues.apache.org/jira/browse/LUCENE-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546702

>> ]
>>
>> Mark Miller commented on LUCENE-1026:
>> -------------------------------------
>>
>> Hey Mark, few more questions:
>> 1. Why is StopWatch needed?
>>
>> StopWatch could certainly be taken out. I simply used it for 
>> timing...to show someone else that it doesn't take that long to get 
>> an accessor. I have no problem with removing it.
>>
>> 2. No need to synchronize on this since you're only returning the 
>> value, not performing any modifications to it.
>>
>> Its possible this could be taken out. I doubt there would be any 
>> noticeable trouble if you tried to read that value while another 
>> thread was updating it.
>>
>> 3. open() - is there a real need to throw an exception if someone 
>> called the accessor.open() twice?
>>
>> No real need I suppose. I believe this came in from the original 
>> code. I have no objections to taking it out.
>>
>>
>> SimpleSearchServer is an attempt to give an example that shows how 
>> this code can be used to create a very simple class that allows 
>> multi-threaded access to a Lucene index. I whipped it out extremely 
>> quickly, but its something I would like to build on. It can be nice 
>> to hide the IndexAccessor code behind a simple to use class that 
>> hides Lucene and a lot of complexity.
>>
>> Thanks for your work on this!
>>
>> - Mark
>>
>>> Provide a simple way to concurrently access a Lucene index from 
>>> multiple threads
>>> --------------------------------------------------------------------------------

>>>
>>>
>>>                 Key: LUCENE-1026
>>>                 URL: https://issues.apache.org/jira/browse/LUCENE-1026
>>>             Project: Lucene - Java
>>>          Issue Type: New Feature
>>>          Components: Index, Search
>>>            Reporter: Mark Miller
>>>            Priority: Minor
>>>         Attachments: DefaultIndexAccessor.java, 
>>> DefaultMultiIndexAccessor.java, IndexAccessor.java, 
>>> IndexAccessorFactory.java, MultiIndexAccessor.java, 
>>> shai-IndexAccessor-2.zip, shai-IndexAccessor.zip, 
>>> shai-IndexAccessor3.zip, SimpleSearchServer.java, StopWatch.java, 
>>> TestIndexAccessor.java
>>>
>>>
>>> For building interactive indexes accessed through a network/internet 
>>> (multiple threads).
>>> This builds upon the LuceneIndexAccessor patch. That patch was not 
>>> very newbie friendly and did not properly handle MultiSearchers (or 
>>> at the least made it easy to get into trouble).
>>> This patch simplifies things and provides out of the box support for 
>>> sharing the IndexAccessors across threads. There is also a simple 
>>> test class and example SearchServer to get you started.
>>> Future revisions will be zipped.
>>> Works pretty solid as is, but could use the ability to warm new 
>>> Searchers.
>>
>> -- 
>> This message is automatically generated by JIRA.
>> -
>> You can reply to this email to add a comment to the issue online.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message