[Edit: This was a follow up to a post on JPA, Hibernate and Toplink, which has disappeared. I know I posted it because Google has it, but sadly not in cache! I must have deleted it but no idea how… ]

Following up on my previous post around an hour ago, Hibernate Search (that is Hibernate integrated with Lucene) does indeed work perfectly. Setting up entity beans for indexing and performing search is easy.

Almost prefect - another couple of out of heap size messages due to the single transaction which batches up 20000 documents (around 75mb on disk) and which is held in memory for Lucene to index on commit. Hibernate seems to do fine persisting this to the database though obviously  Lucene has more work to do at commit point and runs out of memory constructing the index.

I could of course increase the heap size but instead simply batch off the transaction to commit 1000 documents at time. There is another way of doing that but it’s similar in results/method. I chose to explicitly batch the transaction simply so that I keep the database and index in harmony (and don’t have to worry about rollbacks to different stages).

Might be worth getting the Hibernate Search in Action book, though I think that you’d been to be doing some complex search and entity mapping in order to require more than the basic.

As an aside, I seem to be coming across JMS more and more in ‘everyday applications’. For example, Hibernate Search uses JMS for dedicated indexing, Glen Smith talks about his use of JMS for his Groovy Blog app and LinkedIn presented their JMS based architectured at JavaOne 2008. Make me wonder if JMS is the pragmatic, bloatfree ESB?