-
Bug
-
Resolution: Done
-
Major
-
4.1.0.CR2
-
None
-
High
For the segments file only Lucene uses a flush()+commit() semantics, which is currently mapped as put()+put() twice, while we could actually put it at commit only.
Also as we're using the SKIP_LOCK flag on the byte[] of the contents of this file, which never changes, it's not deterministic which value is pushed to the cache, as the second's put() value contains the checksum too and the first not, the index looks like corrupted if the first put() is accepted only.
Going to use batching around this, to properly implement commit() semantics delegating to an eventual transactionmanager, as suggested by Lucene's design of flush+commit.
- is related to
-
ISPN-575 Wrong reordering of data when using Flag.SKIP_LOCKING and having a cache store enabled
- Closed