[
https://issues.apache.org/jira/browse/LUCENE-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464385
]
Doron Cohen commented on LUCENE-771:
------------------------------------
I have a question on this change - though I didn't look at the code yet - we
don't support backwards compatability with regard to existing lock files,
right? Specifically, if there exist an older version index with locks in tmp
dir, and the Lucene lib is replaced for one client at a time, while other
clients are running, there would be a problem, possible corruption. So who ever
is migrating from an index before this change to an index with this change
should make sure that all clients are upgraded at the time. At least all
clients that may attempt to write.
> 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]
