This list is not for support, it's for the development of Hibernate. You can take your question to the forums or raise a JIRA if you think you've found a bug.

Best,

Chris

Yan Falken wrote:
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
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Reply via email to