lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Smiley <dsmi...@mac.com>
Subject Re: Thread safety
Date Fri, 14 Jun 2002 04:48:03 GMT

On Thursday, June 13, 2002, at 12:14  PM, Mark Harwood wrote:

>>> Maybe I'm just not with it right now... but that matrix doesn't seem
>>> to make sense to me.  From my understanding, two write requests
>>> cannot happen concurrently,
>
> This is about the thread safety built into Lucene.

I think that if you want to indicate _thread safety_ (as opposed to 
concurrency characteristics) then simply, class by class, indicate if 
it is thread-safe or not or elaborate as necessary.  One might want 
to elaborate on how to get several operations to act atomically (like 
a transaction).  If this can't be done (not likely, but there may be 
some existing gremlins), then the threading properties of lucene 
should be tweaked a little.  For example, see the documentation for 
the Collections API, Hashtable, and InitialContext.  These are well 
documented with respect to thread-safety.  Strangely enough, JDBC is 
not.  FWIW, I treat Connection as thread-safe but most of the rest of 
the API as not.

> It looks to me like lucene
> looks after the contention between two concurrent "writing" threads, 
> hence the
> "Y" in that intersection. The "N"s mean that Lucene does NOT look 
> after the
> contention and it is an exercise for the lucene user to ensure this 
> situation
> does not occur (eg not deleting a doc while there is a writer open).

I don't think a good indexer should have any Ns on that matrix if the 
matrix is to be interpreted as you have described it.  It /appears to 
me/ that the matrix represents "what can happen at the same time" --a 
concurrency characteristic, not thread-safety.  An example is that an 
index can only be mutated by one thread.  These things are important 
to know for efficiency reasons, not program correctness --as is what 
thread-safety is important for.

> I may be wrong in some of these observations which is why I would 
> like the
> feedback :)
> As for the layout - yes this is a problem with these sorts of 
> diagrams as
> there are always two intersections essentially saying the same thing 
> (Xaxis
> Read, Yaxis write and Xaxis write, Yaxis read) I guess you could but 
> "n/a" in
> the duplicate intersections but I'm not sure if that would confuse 
> people even
> further.

IMO make it a triangle.

> I definitely think some form of documentation about the contention 
> that needs
> to be managed by the lucene user is a useful goal though!

Oh absolutely, it should be a requirement.  Databases do this 
(clearly) and so should an index.  It's good to see that this is 
starting to happen now.

~ Dave Smiley


--
To unsubscribe, e-mail:   <mailto:lucene-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-user-help@jakarta.apache.org>


Mime
View raw message