[hibernate-dev] hibernate search + indexing with transaction issue

[Emmanuel Bernard]

Good question.

return;  is what is expected (see HSEARCH-257).
The scenario you are describing (delete + add in the same transaction)  
cannot happen in Hibernate unless you use assigned ids and don't have  
any kind of association in your object. Even in this case you are  
cheating the system. Allowing delete + add kinda reopens HSEARCH-257.

Next time use the forum, it's easier for everyone. And of course, if  
you need "ASAP" answers, we have a for pay support. Hibernate Search  
in part of our supported platform.

On  Mar 23, 2009, at 09:00, Yan Falken wrote:

> Hi,
>
> I have the following problem with indexing in transaction with  
> hibernate
> search: in case the transaction is opened and I want to perform  
> multiple
> work types - only one type is actually performed after the commit  
> and the others are
> ignored; example:
>
> TransactionManager tm = new DummyTransactionManager();
> tm.begin();
> SEntity se1 = new SEntity(10, "first", "second", true);
>
> Work delete = new Work(se1, "100", WorkType.DELETE);
> Work add = new Work(se1, "100", WorkType.ADD);
>
> Ctx ctx = new Ctx(tm.getTransaction());
> searchFactory.getWorker().performWork(delete, ctx);
> searchFactory.getWorker().performWork(add, ctx);
>
> tm.commit();
>
> only DELETE is performed - ADD is ignored
>
> log:
>
> 2009-03-23 13:45:02,195 TRACE                 main|        
> MaskedProperty| found a match for key:  
> [hibernate.search.default.indexBase] value: /tmp/c1idx
> 2009-03-23 13:45:02,195 TRACE                 main|        
> MaskedProperty| found a match for key: [default.indexBase] value: / 
> tmp/c1idx
> 2009-03-23 13:45:02,341 DEBUG                 main|  
> BuilderIndexedEntity| Field selection in projections is set to false  
> for entity problems.SEntity.
> 2009-03-23 13:45:02,502 DEBUG      pool-1-thread-1|   
> PerDPQueueProcessor| Skipping usage of an IndexWriter for updates
> 2009-03-23 13:45:02,503 TRACE      pool-1-thread-1|   
> PerDPQueueProcessor| Locking Workspace (or waiting to...)
> 2009-03-23 13:45:02,503 TRACE      pool-1-thread-1|   
> PerDPQueueProcessor| Workspace lock aquired.
> // opened
> 2009-03-23 13:45:02,503 DEBUG      pool-1-thread-1|   
> PerDPQueueProcessor| Opening an IndexReader for update
> 2009-03-23 13:45:02,503 TRACE      pool-1-thread-1|             
> Workspace| IndexReader opened
> // only remove
> 2009-03-23 13:45:02,503 TRACE      pool-1-thread-1|  
> eleteExtWorkDelegate| Removing class problems.SEntity#100 by id  
> using an IndexReader.
> 2009-03-23 13:45:02,539 TRACE      pool-1-thread-1|             
> Workspace| IndexReader closed
> 2009-03-23 13:45:02,539 TRACE      pool-1-thread-1|   
> PerDPQueueProcessor| Unlocking Workspace
>
> I digged into the code a little bit and there is class method:
>
> org 
> .hibernate 
> .search.engine.DocumentBuilderIndexedEntity.addWorkToQueue() which  
> is in it's beginning iterating the existing queue to avoid  
> unecessary duplicated works
>
> if ( workType == WorkType.DELETE ) { //TODO add PURGE?
> 	//DELETE should have precedence over any update before (HSEARCH-257)
> 	//if an Add work is here, remove it
> 	//if an other delete is here remember but still search for Add
> 	if ( luceneWork instanceof AddLuceneWork ) {
> 		toDelete.add( luceneWork );
> 	}
> 	else if ( luceneWork instanceof DeleteLuceneWork ) {
> 		duplicateDelete = true;
> 	}
> }
> else {
> 	//we can safely say we are out, the other work is an ADD
> 	return;
> }
>
> I believe that return should be changed to continue. I did several  
> tests and after the change it can handle ADD/DELETE works in one  
> queue.
>
> Could you confirm this and tell me in case it's correct how fix  
> should be raised? Please ignore this email if its design limitation  
> and the multiple WTs cannot be fixed easily.
>
> Thanks
> YF
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev