2

We are working on a JavaFX solution using Hibernate/JPA to access the database. We use Hibernate Search with Lucene to search for entities, which works quite well, as long as only one instance of the program is running. If a second instance is started, the search still works, but updating the entities fails, because the first started application keeps the write lock on the index. We are not using any kind of JavaEE application server, the JavaFX client accesses the database directly via Hibernate.

In the final productive environment there will be one MS-SQL server holding all the data and several rich clients running on the server in virtual machines or reaching the database server via VPN. I would like to enable that all clients can add and edit entities and get the index updates immediately. I already tried to find a solution with Infinispan, but didn’t really grasp where to start and what to do exactly.

Can anyone give me an idea on how to accomplish this? Is it possible to save the indexes directly in the database or start some kind of service where the clients can access the current index?

YellowSub
  • 179
  • 2
  • 11

2 Answers2

3

There are multiple options.

  1. like Guillaume Smet suggested, externalise the index to an Elasticsearch cluster. That can scale up, but might be overkill for small deployments.
  2. Set the configuration property hibernate.search.default.exclusive_index_use=false and point the apps to the same directory; they will be able to share it but they will have to "take turns" for write operations. See also Table 3.7. List of indexing performance and behavior properties.
  3. Store the index in an Infinispan Directory (an in memory-distributed data grid). The distribution aspect might be overkill, but it's able to offload storage to a relational database. See Infinispan Lucene Directory and JDBC Cache Store

Since you mentioned clients running over a VPN, I would not suggest to run Infinispan in cluster mode as its meant for high-performance (local) links, but you can still use it in "local mode" for each of them to read the updated index via the JDBC cache store. This solution however will only be efficient if writes are not very frequent, as each client will need to download large chunks of data on each index update. The second solution would require each client to mount a shared filesystem, which equally will require downloads and caching.

Sanne
  • 6,027
  • 19
  • 34
1

I think it's probably a good use case for you to test our new Elasticsearch integration.

We released 5.6.0.Final with Elasticsearch support today. See http://in.relation.to/2017/01/30/hibernate-search-5-6-0-Final-and-5-7-0-CR1/ for more information about it.

Note that if you use ORM 5.2.x, you will need to use our 5.7.0.CR1 (which is basically the same as 5.6.0.Final with support for ORM 5.2.x).

This support is still experimental (experimental meaning that we might change some API in the next version) at this point but I think it's definitely worth a try for your use case.

Guillaume Smet
  • 9,921
  • 22
  • 29