[
https://issues.apache.org/jira/browse/LUCENE-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464409
]
Michael McCandless commented on LUCENE-771:
-------------------------------------------
You're right, backwards compatibility will allow a 2.1 client to
read/write to an older index, but as soon as a 2.1 client writes to
the index then all pre-2.1 readers won't be able to read it. You're
right that if these readers are not reopened then "point in time"
would allow them to keep running pre-2.1.
So I think you could individually update each reader to 2.1, but then
(after readers are updated), all writers would need to go to 2.1 at
once, to make sure they all "agree" that the write lock is now in the
index.
> Change default write lock file location to index directory (not
> java.io.tmpdir)
> -------------------------------------------------------------------------------
>
> Key: LUCENE-771
> URL: https://issues.apache.org/jira/browse/LUCENE-771
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Store
> Affects Versions: 2.1
> Reporter: Michael McCandless
> Assigned To: Michael McCandless
> Priority: Minor
> Fix For: 2.1
>
>
> Now that readers are read-only, we no longer need to store lock files
> in a different global lock directory than the index directory. This
> has been a source of confusion and caused problems to users in the
> past.
> Furthermore, once the write lock is stored in the index directory, it
> no longer needs the big digest prefix that was previously required
> to make sure lock files in the global lock directory, from different
> indexes, did not conflict.
> This way, all files related to an index will appear in a single
> directory. And you can easily list that directory to see if a
> "write.lock" is present to check whether a writer is open on the
> index.
> Note that this change just affects how FSDirectory creates its default
> lockFactory if no lockFactory was specified. It is still possible
> (just no longer the default) to pick a different directory to store
> your lock files by pre-instantiating your own LockFactory.
> As part of this I would like to remove LOCK_DIR and the no-argument
> constructor, in SimpleFSLockFactory and NativeFSLockFactory. I don't
> think we should have the notion of a global default lock directory
> anymore. This is actually an API change. However, neither
> SimpleFSLockFactory nor NativeFSLockFactory haver been released yet,
> so I think this API removal is allowed?
> Finally I want to deprecate (but not yet remove, because this has been
> in the API for many releases) the static LOCK_DIR that's in
> FSDirectory. But it's now entirely unused.
> See here for discussion leading to this:
> http://www.gossamer-threads.com/lists/lucene/java-dev/43940
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
