cancel
Showing results for 
Search instead for 
Did you mean: 

Lucene search returns out of sync data within transaction

timster
Champ in-the-making
Champ in-the-making
We're getting into the nuts and bolts of Alfresco for some work we're doing, and i'm running into a data sync issue with one of the unit tests I've written.

We are using Spring's transactional setup, which Alfresco is picking up very nicely, and you all may be aware that Spring has transaction-enabled junit classes that let you run a single junit test within a transaction. 

So, what I am seeing is in a simple test where at the start of the test method (but within the transaction), I populate the repository with several objects which are written to their respective nodes. 

Then I run certain methods to ensure that the objects are inserted correctly, the parent-child relations are correct, and to return a count of all existing objects of that type.  We are using a lucene search for the last operation (returning a count of all objects of that type).

With inserts and updates, everything is fine.. but once I run a delete operation using NodeService.delete(nodeRef) on some of those objects and run the checks, lucene returns the wrong count.  It returns the original count of objects, instead of the revised count. 

Example, if I insert 4 Topics, and do .getTopicCount(), i get 4.  So far so, good, then I do NodeService.delete(t1.getNodeRef()), and then run .getTopicCount() again, I still get 4, instead of 3. 

Seems to me that within a transaction, the Lucene index is not being updated correctly for deletions.   I'm hoping that someone at Alfresco can tell me whether this is expected, or not - and how to get around it. 

I hope we do not have to split them up across transactions, because we are likely to be combining multiple operations within a single tx using a command type pattern.  Thanks!
2 REPLIES 2

andy
Champ on-the-rise
Champ on-the-rise
Hi

This behaviour is not expected.

It seems a delete against data added/changed in the transaction may not be picked up if it is the last action on the transaction. (In the unit test there is an add after the delete - I have split this out and reproduced the issue). If a pre-existing node is deleted the behaviour is OK, if you add or update a node the count will be correct.

See http://www.alfresco.org/jira/browse/AR-549
The fix will go in soon and is added as a comment to the bug.


Regards

Andy

andy
Champ on-the-rise
Champ on-the-rise
Hi

This is fixed in the HEAD code stream.

The committed index will be correct.

The only way you can work round this is to update any node after the delete, get the fixed code, or apply the same fix.

Regards

Andy