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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
