ok - I think it should support multiple works as there is no way to
control clients to do just one operation type - and I think
therefore it can be considered as a bug ... please can someone from HS
team look at it and clarify ASAP?
thanks
YF
On Mon, Mar 23, 2009 at 02:00:50PM +0100, 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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
