对当前已在Lucene中合并的索引调用Commit

我的问题被认为是Lucene.NET2.9.2

假设我使用

IndexWriter

更新了一个索引，这导致调度程序开始在后台合并段。如果在合并完成之前调用

Commit

，会发生什么？调用

Commit

的线程将被阻止并等待合并完成，还是两个线程是独立的

答案对我的搜索实现非常重要，因为我依赖于

字段缓存

来解决性能问题，如果

提交

不会等待合并完成，我可能会得到错误的文档ID

更新：

我试图做的是DocId到Appliciation Id之间的映射，所以在使用

indexsearch

搜索方法时，我不需要获取应用程序Id的存储值。 因此，我尝试在索引期间构建映射，将该映射保存到一个二进制文件，并在搜索中将该文件加载到一个数组中（内存中…）。因此，文件版本必须与

IndexReader

一致（希望清楚…）

例如： （索引过程代码）

IndexWriter-writer=//初始化writer
//使用writer add\delete\update doc方法修改索引。。。
//获取索引的更新读取器
IndexReader r1=wrtier.GetReader（）；
//读取特定字段名的所有文档的所有值。
long[]ids=FieldCache_Fields.DEFAULT.GetLongs（r1，“ID”）；
//将数组序列化为文件（未提供代码）
字典元数据=新字典（）；
添加（“文件名”，序列化文件的完整路径*/）；
提交（元数据）；

（搜索程序代码）

IndexReader r2=//IndexRead.Open。。。
字典元数据=r2.GetCommitUserData（）
字符串fullPathToFile=元数据[“文件名”]//获取已序列化的文件名
//从文件加载数组（=反序列化文件）
long[]id=//从文件加载
//现在，我可以将内部DocId转换为我的应用程序Id，并节省时间，而不是从存储字段获取数据（这需要更多时间…）

---

基本上，我的问题是：假设没有对索引进行其他修改，那么两个阅读器r1和r2的docId是否有可能不合适？

后台合并不会阻止您的提交

---

但是我不理解你的

FieldCache

问题：

IndexReader

s是不可变的，FieldCache实例永远不会失效。

你使用的是什么版本的Lucene？谢谢你的回复。你说得对，我对这个问题还不够清楚。我用我的目标更新了我的帖子，希望它更清晰一点。我不明白你为什么不直接使用字段缓存生成字段缓存非常耗时-对于包含5M文档的索引，大约12秒。你是否尝试过使用每个段的字段缓存？看起来您真正需要的是DocValues（在Lucene Java 4.0中提供），不知道Lucene.NET的状态是什么。

IndexWriter writer = //initialize writer

//modify index using the writer add\delete\update doc methods...

//get updated reader to the index
IndexReader r1= wrtier.GetReader();

//read all values for all documents for specific field name.

long[] ids = FieldCache_Fields.DEFAULT.GetLongs(r1, "ID");

//serialize the array to a file (code not provided)

Dictionary<string,string> metaData = new Dictionary<string,string>();
metaData.Add("FileName", /*full path to the serialized file*/);
writer.Commit(metaData);

IndexReader r2 = //IndexRead.Open...
Dictionary<string,string> metaData = r2.GetCommitUserData()

string fullPathToFile = metaData["FileName"];  //get the file name that was serialized

//load the array from the file (=deserialize file)
long[] ids = //load from file

//now I can convert internal DocId to my Application Id, and save time instead of fetching data from the stored field (which takes more time...)