Hi all, I have a searcher and a writer, the writer writes N changes, then the searcher is reopened to reflect them. Depending on whether autoCommit is false or true for the writer it could have to be closed after the N-changes batch too, just to make visible the flushed changes. But suppose for now that autoCommit=true (classic behaviour).
The index itself references external documents by id, when these documents are added or changed a correspondent update in the index takes place. The external documents have a couple of timestamps indicating one the date of the last document change and the other the last time the document was indexed. Of course, if the first timestamp is newer than the second one, the index must be updated for that document. If and only if this update is successfully carried on, the indexed timestamp has to be updated, that is to mark the document as indexed. The point is that I don't know how to ensure that the index update is in fact persisted to disk except by flushing after every M changes by myself. Also, if there were some callback mechanism by which my app could be told of flush events, I would update the timestamps just for the effectively flushed documents; but I'm not aware of such feedback mechanism. Then, it's still another history with autoCommit=true, because I know changes are not committed before the index is closed, this could be a beginning but I still don't know if that close operation is in fact atomic. What do you suggest? Thank you in advance. Regards, Carlos
