Sorry, I am using "gets lock" to mean 'opening the index'. I was
simplifying the the procedure.
I think your comment is not correct in this context.
On Jan 24, 2008, at 3:16 AM, Michael McCandless wrote:
Doron Cohen wrote:
------=_Part_11325_2615585.1201162438596
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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).
Aha, you are right Doron! Indeed Lucene effectively serializes
this case, using the write.lock.
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.
And, in this case, B will fail when it tries to get the lock. It
must be re-opened so it first sees the changes committed by A.
So, Lucene is transactional, but forces clients to serialize their
write operations (ie, one cannot have multiple transactions open at
once).
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
