In our web application, I have created the index of required data. Now through web application any new data is inserted, updated or deleted, i want to update the corresponding index asynchronously. May be immidiattely or after some time interval. I don't want to increase the response time for front-end user. For this, i think following two approaches.

(1)
One approach is to use Hib search JMS backend. In one of the forums emmanuel wrote:

if you want to index changes made by hibernate but apply them only once a day, your best bet is to use the JMS back end. You just have to enable your Message Driven Bean to process the messages once a day. There is virtually no overhead in using this method for your front end.


but i m not clear how to implement this. and how to configure my hib search to use JMS backend. I have read the hib search doc, but it's not very clear from doc. In doc, JMS config is described for clustering. but i am having a single instance of my web app. If there is any example code or someone has already done, it would be a great help.

(2)
Second approach is to extend the FullTextIndexEventListener class and override the onPostXXX methods and configure these event listeners. In these overidden methods, i write the code to store the recieved entity into JMS Queue. and then after some regular time interval, i process the entity from the queue and update the corresponding index manually.

Can anyone suggest what should be the best approach ?

Thanks,
Bhavin

I believe option one is indeed the easier and better one to set up. How you go about it depends on the type of your application and especially in which container you are running. If for example you are running in a JBoss container you really just have to write and deploy a single MBean.

However, I also managed to successfully configure a Master/Slave setup using Tomcat together with ActiveMQ which is described here: http://www.hibernate.org/421.html. The problem is less writing the code, but more understanding how to setup and configure JMS.

Have you actually tried synchronous index updates? Index updates are incremental and quite fast. Besides, while the index gets updated it is still searchable. If you only have a single application instance (unclustered) I would recommend starting of with a synchronous indexing approach and test the performance. Configuring a JMS backend is an orthogonal problem which you can easily tackle later in case performance becomes an issue (or you want to cluster your application). The only changes in your application will be the configuration and the addition of a MBean. Writing your own EventListeners is a much more invasive approach.

I hope this helps :)

--Hardy

Option 2 will not work as you describe it. You will have to think about it deeper (especially there are sole lazy loading business going on).

An alternative to not hit the request / response time for a given user is to use the local asynchronous mode



It will delegate the work to a local thread pool and avoid all the JMS machinery. Quite nice if you don't want several instances running.

http://www.hibernate.org/hib_docs/search/reference/en/html_single/#d0e718
http://www.hibernate.org/hib_docs/search/reference/en/html_single/#d0e449

Thanks a lot for your suggestions.
I am currently trying what you have suggested. Let u know my findings.

Thanks,
Bhavin