On Jan 24, 2008 12:31 AM, robert engels <[EMAIL PROTECTED]> wrote: > You must get the write lock before opening the reader if you want > transactional consistency and are performing updates. > > No other way to do it. > > Otherwise. > > A opens reader. > B opens reader. > A performs query decides an update is needed based on results > B performs query decides an update is needed based on results > B gets write lock > B updates > B releases > A gets write lock
Lucene actually protects from this - 'A' would fail to acquire the write lock, with a stale-index-exception (this is tested in TesIndexReader - testDeleteReaderReaderConflict). > A performs update - ERROR. A is performing an update based on stale data > > If A & B want to update an index, it must work as: > > A gets lock > A opens reader > A updates > A releases lock > B get lcoks > B opens reader > B updates > B releases lock > > The only way you can avoid this is if system can determine that B's > query results in the first case would not change based on A's updates. >
