hibernate.search.worker.batch_size and cluster ing

skalyana1006 · **Joined:** Wed Jul 09, 2008 8:55 pm **Posts:** 9

Hi,
I have a question on worker.batch_size. If I set this to say 1000, and if i have automatic indexing to synch entity changes with index.

1. Does it mean that even though a particular entity is changed and committed to the database, the index update wont happen untill 1000 changes have accumulated?
2. Or is it, purely from a batch entity update or index perspective, where if we update or index 1000's at a time, index will be updated at every 1000 change accumulation. But, individual entity changes are reflected instantaneously in the lucene index?
3. The reason, I am asking this is: If I have multiple nodes of JBOSS/hibernate pointing to the same data(say oracle), will i have a problem where
node1 added an entity at time T1
node2 updated the entity at time T1 > T2
node1 deleted that entity at time T3 > T2

when node 2 batch size comes to a full 1000, the entity update will create a fake lucene index entry eventhough the entity should actually be deleted.

Sorry, if this is too confusing

thanks!!

hardy.ferentschik · **Posted:** Tue Aug 12, 2008 6:29 am

Hi,

I think this few lines from the online doc should answer your question:

Quote:

To avoid that, you can set up the hibernate.search.worker.batch_size property to a sensitive value: all index operations are queued until batch_size is reached. Every time batch_size is reached (or if the transaction is committed), the queue is processed (freeing memory) and emptied. Be aware that the changes cannot be rollbacked if the number of index elements goes beyond batch_size. Be also aware that the queue limits are also applied on regular transparent indexing (and not only when session.index() is used). That's why a sensitive batch_size value is expected.

Does this answer your question?

--Hardy

emmanuel · **Posted:** Tue Aug 12, 2008 2:33 pm

Please don't cross post on both forums, this makes us work twice for the same issue.