Hi,

I am working on sending/receiving messages to/from JMS on my own, indepedent of HS. I listen to onFlushEntity and send the indexable objects to the JMS queues. There is a queueReceiver that listens to the JMS queue and manually index the object.

It throws a "org.hibernate.TransientObjectException: The instance was not associated with this session" when the manual indexing is called. I understand that the object is not attached to the current session. However, I do not need it be attached to any session as there is no need to persist the object to the db for the queueReceiver.

May I know if the manual index requires the object to be attached to the session? Is there a workaround? Why does it connect to the db? It only need to update the indexed files, right? Any motivation for this?

What does HS send to the JMS queues that could handle this? I supposed HS does not send the object to the JMS queue?

Hi,

You approach has several shortcomings. First your entities need to be Serializable in order to put them onto the queue and second how do you handle lazy loaded fields? In your particular case this may be no problem, but generally it is not a good idea. Hence, Hibernate Search put instances of LuceneWork on the JMS queue which contain the already assembled Lucene documents (and a little more).
And yes, you will need a current session. FullTextSession sits on top of Hibernate Sesssion and there are some dependencies.
Have you tried the JMS setup Hibernate Search provides?

--Hardy

Due to some security concerns, I cannot employ HS master-slave architecture. I need a separation between the index layer and web layer, where
- the web tier cannot contain indexed files. (cannot apply HS master-slave)
- the index tier does indexing and service search requests forwarded from web tier. (Solr seems to be a good fit here)

I'm actually trying to achieve a hybrid HS and Solr. I built Jetty on top of a standalone HS in the index tier. It reads objects from JMS to index and entertain search requests forwarded from web tier. However, packing the search results(objects) to XML and transmit to web tier seems to lose the benefits of HS (like ability to update the managed object).

May I know what is the direction for HS? Will HS implement Jetty in future and be able to replace Solr? Could u give me advise whether should I proceed with this or use Solr?

I understand that HS is planning to resolve the current limitation of a single writing master node, what other plans does HS have with regards to my issue?

Thanks in advance!

If this is a hard requirement then Solr might indeed be the better fit. However, what are the issues you are having with having the index files on the web layer?


That sounds wrong. It should be just one of them. Having HSearch and Solr just increases the number of technologies you have to master.


That's right. There doesn't seem much value in HSearch in this case.


I don't understand you question. Jetty is a webcontainer like Tomcat. Hibernate Search is a freetext search engine. You are comparing apples with pears here. And no HSearch will not replace Solr. They are two different products which serve different use cases as you already have discovered. There is a need for both products.

--Hardy

about this exception, I'm guessing the entities you need to build the Document are not fully initialized. you likely want to reattach them to a session before converting to Lucene Documents.
The safest way is likely to transmit the type+PK only, not the whole entity, so you're sure it's consistent and not having pieces of information loaded from different transactions.
Even better, transform them into Lucene Documents in the web tier, and send the Documents to the queue: that's what the Hibernate Search implementation does.

Totally agree with Hardy to keep the number of technologies to the minimum, but we might eventually consider building a custom backend which sends XML changesets to Solr. Definitely, I'd avoid remote query, seems a useless overhead and big lack of flexiility as you wouldn't have the Lucene direct API available anymore. So this Solr integration I was thinking about is just useful to integrate with other languages or complex environments having many systems speaking to the same Solr service.