Hi, sorry for my English.
My index is not updating until hibernate.search.worker.batch_size=1, but this propery is deprecated. In another way I can't write changes to index immediately after saving/updating the object.

Properties



not help.

Anybody can help me?
Thanks.

P.S. (Hibernate Search 3.1, Hibernate 3.4, Hibernate annotations 3.4)

Hi, are you using transactions and committing properly?

Yes. I am using Hibernate with Spring.
Also, when I try to reindex my data without option hibernate.search.worker.batch_size some data with small number of elements are not reindex.

I previously posted here:

http://forum.hibernate.org/viewtopic.php?t=988824

Updates were never making it into the index, but were showing up in memory, although you could not search by the new values themselves. New object were also not getting into the index and were never searchable.

However, once I added:

<prop key="hibernate.search.worker.batch_size">1</prop>

to my spring properties...viola. Now all changes are immediately searchable and make their way to the index. My guess is such a small batch size won't be all that performant...but at least it works.

So is this a bug or is there something else that we need to do to make this work without setting such a small batch size...or is that just expected behavior (in which case some documentation or entry in the FAQ would be nice)?

Hi,
no this is not expected behavior of course,
please open a new issue on JIRA:
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH

thanks,
Sanne

I've taken some time to experiment with this, but couldn't reproduce it.
could someone provide a test case or a simple piece of code to show me the problem?

Hibernate Search 3.1 CR1 - the same problem.

I asked this already: are you committing the transaction?
I don't know how Spring works.

The changes to the index are visible only to a transaction beginning after the commit of the transaction who did the changes, this is by design.
Limiting the batch_size to 1 is just breaking the design, it is not going to be in sync with transactions (quite dangerous, should really avoid it)

Yes. I am committing the transaction (Spring do this automatically, autocommit is turned off).
I am using JTA (Glassfish).

Hi,

here are a few of my observations. I hope some of them might help you to resolve your problem.

First of all, I don't think that your chosen properties values for max_buffered_delete_terms, max_buffered_docs, etc are very good. They are pretty much all set to their required minimum. I don't think that you will get very good performance with these settings. You might be better of with the default values.

Regarding hibernate.search.worker.batch_size=1, the reason it works is that with this value set to one you are pretty much bypassing the transactional framework. Each index modification will be applied immediately. As Sanne already pointed out, this is probably not a good idea and might be even dangerous. Index changes might get applied even though your db transaction might for example roll back due to an error. In this case you end up with a corrupted index. Everything indicated a problem with transactions.


How do you know that updated where showing up in memory, if the changes were never searchable. I am not quite sure what you are referring to here.


Definitely not an intended behavior.

Regarding your Spring setup. Which version of Spring are you using and how are you using it? Which type of transaction management do you use? Programmatic or declarative? Do you use any of the Spring Hibernate templates? If you are using declarative management (which I would recommend) maybe it helps if you compare your configuration with this article on the Hibernate Wiki - Spring + Hibernate + Hibernate Search. The article references older versions of Search and Spring, but it should work with the latest version as well.

It would also help if you would post the code you are using to update and search your entities. This together with some log output might help to narrow down your problem.

Last but not least, I recommend to turn on Spring debug trace and trace the transaction log messages. Do they really behave as you expect? For example if you update an entity and then want to search on it, there must be at least one transaction commit in between.

--Hardy

This problem only with JtaTransactionManager.
With HibernateTransactionManager all working fine.

Any suggestions?

Hi,

it is probably a configuration problem. How do you setup the JtaTransactionManager and how do you use it. Probably a good idea to look and ask at the Spring forums as well.

--Hardy

This is my configuration. (commented configuration is working fine)

Hi, why not use org.springframework.orm.jpa.JpaTransactionManager as in the example configuration I was referring to earlier?

My understanding is that you somehow have to 'bind' your transaction manager to either the EntityManager (JpaTransactionManager) or to the Hibernate Session (HibernateTransactionManager). I don't think that JtaTransactionManager works in this case. Then again, I am not a Spring expert. Try asking the question on the Spring forum.

--Hardy

I am not using JPA. I need JTA with transaction configuration outside application (app server admin console).

But Hibernate Search 3.0 working fine with JtaTransactionManager.
I am confused...