Lucene Index - Read Committed

[rsoika]

Read Uncommitted

In the current version Lucene Index works with an Isolation level equals to 'Read Uncommitted'. This means, during a transaction each client reads the uncommitted index. This means a different transaction read changed index by an transaction which is still in progress. This leads to Dirty reads. In addition a rollback did not update the index. This my lead to kind of unexpected behavior and errors.

Read Committed

The solution is an implementation of "Read Committed". This means a transaction can not search in a uncommitted index. Index updated by different transaction which is still in progress can not be read. Dirty reads are prevented.

Solution

The LuceneIndexWriter writes a LucenEventLogEntry each time a client requests an update. This is called the EventLogCache. When a client reads the index, the LuceneIndexSearchService calls the method "flushEventLogCache" of the LuceneIndexWriter. This is a method running in a new Transaction (annotation TransactionNew). The method checks if committed EventLog entries exits. If so the method updates the index first. This new behavior will have a tolerable impact on performance as the first read call must wait until the index was refreshed. Writes become a little bit faster.

[rsoika]

Started branch 'issue-411'

[rsoika]

In case that the dertyIndex flag is set to "true", but the flushCache method did not find any event log entries, than we should not reset the dirtyIndex flag to false because there is still a uncommitted transaction running. How to solve this issue?

[rsoika]

Check if this affects the inernal method call "isCallerReader".
This method did not check the data obejct for null!

possible solution:

	 * In case the document is not yet full initialized and has no data, the method returns true. 
	 * 
	 * @return true if user has readaccess
	 */
	private boolean isCallerReader(Document document) {

		if (document==null || document.getData()==null) {
			// method is called on non not fully persisted document
			return true;
		}

[rsoika]

To avoid a conflict with the snapshotservice we need to prafix the eventLogEntryID instad of sufix the eventLogEntryID.

This is because the snapshotservice constructs the following JPQL which includes the eventLogEntries

SELECT document FROM Document AS document
 WHERE document.id > 'c246275c-f0a0-48c1-b803-f86fef6552e9-'
 AND document.id < 'c246275c-f0a0-48c1-b803-f86fef6552e9-1535232763173'
 ORDER BY document.id ASC