5

I have the following setup:

  • JPA (2.0) through Hibernate (4.1)
  • Infinispan as 2nd level cache (5.1)
  • Hibernate Search connected to Hibernate (4.1)
  • Infinispan as Directory for Hibernate Search (Lucene)
  • Connected a JDBC CacheStore for the Infinispan Directory
  • PostgreSQL (9.1) database to store both entities and Lucene directory.
  • Bitronix (2.1.2) as Transaction Manager
  • I'm not using Java EE, but Spring (3.1)

Infinispan as Second Level Cache is fine, no recovery is needed and you can read changes in your own transaction because of the nature of the Cache.

After hours reading source codes, when I update an Entity, Hibernate Search does not update the Lucene Directory but at the end of the transaction (if it commits), so it I wanted to do a search of the text I've just updated, inside the same transaction, wouldn't I be able?

But moreover, Hibernate Search does the updates to the Directory in a different thread, after transaction completion. So if one of the Directory Updates fails, then Lucene will be inconsistent to my entities? And if something happened before the updates were dispatched to the Directory and a recovery was needed, would those updates be lost?

Assuming this "first" transaction committed successfully, the updates were sent to the Infinispan Directory. A new transaction would be started here. By whom? Lucene has the options to send the updates using JMS. Let's say that option is activated, so the JMS message initializes the new transaction.

Infinispan will modify its memory directory with the updates it receives, but the persistent CacheStore will again be updated at this transaction completion, after commit. Therefore there is a chance that if something happens while updating the jdbc CacheStore, it will be left with no updates, but Infinispan Memory Directory will have them applied.

My question is, considering that all the modules I'm using support transactions, and that they even support joining to global transactions (XA), is there a way to achieve true transactionality? Maybe I'm just not seeing it.

Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
Luciano
  • 8,552
  • 5
  • 32
  • 56

1 Answers1

0

I'm working on a very similar setup. With these versions true transactionality is not possible. There are a few reasons, some of which you have noted:

  1. Hibernate Search does index updates in commit phase
  2. Hibernate Search processes on background threads - even when 'synchronous'
  3. Infinispan cache store updates are done in commit phase

Here the transaction phase is important as the eventual inserts into the database need to be done in the main body of the transaction and committed at the end.

My solution was to ignore transactionality for index updates, it wasn't strictly necessary in my case.

Anuj Shah
  • 71
  • 4