Thanks, you are correct, but I am not sure it covers the complete case.
Change it a bit to be:
A opens reader.
B opens reader.
A performs query decides a new document is needed
B performs query decides a new document is needed
B gets writer, adds document, closes
A gets writer, adds document, closes
There needs to be a way to manually serialize these operations. I
assume I should just do this:
A gets writer
B gets writer - can't so blocked
A opens reader
A performs query decides a new document is needed
A adds document
A closes reader
A closes writer
B now gets writer
B opens reader
B performs query sees a new document is not needed
B closes reader
B closes writer
Previously, with the read locks, I did not think you could open the
reader after you had the write lock.
Am I correct here?
On Jan 24, 2008, at 2:13 AM, Doron Cohen wrote:
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
