Regarding question 1:
Yes the two writes to data & metadata are fully independent, yet if one of them is lost the index is likely corrupted. However remember that Infinispan is an highly available data grid, the DB storage is just the last phase storage: if you have Infinispan configured for replication (or distribution), a failure to write on the database is not a problem as the entries are first and foremost safely stored on the other nodes. In case of a node crash during a DB synch for example, another node will take over and when a read of this specific entry is needed it will be served from there.
In your specific case you're running it with local caches, so replication is not available but the local memory still is. If you had not restarted the application, it is possible that the index state would have survived as there was a functional replica within the Infinispan datacontainer.
Regarding looking at order of stores: bear in mind that - when you use write-behind - the actual writes of the entries to the CacheStore is out of order. There is no guarantee about which entries would have been written first, the only guarantee you have is that it wouldn't overwrite an entry with an older one - nor delete an entry which should not be deleted.
Question 2:
The IndexWriter buffer is before flushing of indexing operations into the index store. So that's before reaching Infinispan. In terms of source code, this means it's within the org.apache.lucene codebase. Flushing operations are controlled by Hibernate Search; depending on your configuration: typically it will flush after each commit of your application's transaction. In case you use NRT then it would flush less frequently - that's why the documentation contains
Quote:
As a trade-off it requires a non-clustered and non-shared index.
: if it doesn't flush, the changeset of the transaction wouldn't be visible to other nodes. (When using NRT the buffers are still usable for local queries, but only to those queries running in the same JVM - with a direct reference to these buffers).
Another case in which flushing is disabled is during MassIndexing operations: flushing would slow it down, and the goal of the MassIndexer is to give you a tool to rebuild the index at maximum speed. It will flush occasionally - depending on when these buffers are full - and once again at the end of the process.
You mentioned invoking FullTextEntityManager.index(object) directly. Why do you do use this method? Most users let it index automatically.
To answer your question: when you invoke that method it will also flush the IndexWriter, at the end of the current transaction if there is any transaction, or immediately if there's no active transaction.
Login
FAQ
Search
