Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Clear the pending indexing tasks at Session.clear()

Description

I have a use-case with a nested transaction in a loop.

When the nested transaction is committed, I manually flush and clear the Hibernate-Session, because otherwise, the program would run into an OutOfMemoryException, because it loads to many objects into the Hibernate session.

Sometimes, the nested transaction is rolled back, to cancel some work, because of invalid data or other errors. In this case I have to clear the Hibernate session, so that the modified objects are not saved by Hibernate.

When the nested transaction is committed and I am flushing the Session, I can flush the FullTextSession accordingly via FullTextSession.flushToIndexes().

But, when the nested transaction has to be rolled back, I am not able to cancel the work recorded by the FullTextSession. FullTextSession.clear() has no effect on the queued work. This leads to errors: because I have flushed the Hibernate session manually, the queued work sometimes is causing LazyInitializationException\s. And: it should not be written to the index, because I have thrown away the modified objects and the index would get out of sync, if the queued work is not canceled.

I searched the documentation and the internet for hours, but I can't find any way, to cancel work.

I think it would be reasonable, to overwrite Session.clear() in FullTextSession and cancel all queued work, like when the session is rolled back. Because, this is, what a user expects, when he clears the FullTextSession.

Another possibility would be, to implement a Method like FullTextSession.clearQueuedWork() or FullTextSession.cancelWork().

Activity

Show:

Yoann RodièreAugust 22, 2019 at 12:27 PM

Fixed in 6.0.0.Alpha9 when the "inner" transactions are actual, separate transactions (PROPAGATION_REQUIRES_NEW in Spring).

Not fixed for "nested" transactions as understood in the Spring world (PROPAGATION_NESTED). Those are not really transactions, just virtual contructs relying on savepoints, and savepoints are not currently supported by Hibernate ORM.

Fabio Massimo ErcoliAugust 22, 2019 at 9:24 AM

It seems that the current version of Spring Data Hibernate JPA dialect does not support nested transaction.
From my understandranding, using Spring framework, nested transactions are possible only using the JDBC (low-level) driver.

Ispecting the code of Spring Data. Looking at JpaTransactionManager#setTransactionData method.
The safepoint manager is set only if the current transactionData is an instance of SavepointManager.

Using Hibernate JPA dialect it is not.
Since the class org.springframework.orm.jpa.vendor.HibernateJpaDialect$SessionTransactionData does not implement org.springframework.transaction.SavepointManager.

The guy who opened the issue used at the time an old Spring version: the 3.2.
It seems that we would had the same limitation at that time:

PROPAGATION_NESTED uses a single physical transaction with multiple savepoints that it can roll back to. Such partial rollbacks allow an inner transaction scope to trigger a rollback for its scope, with the outer transaction being able to continue the physical transaction despite some operations having been rolled back. This setting is typically mapped onto JDBC savepoints, so will only work with JDBC resource transactions. See Spring's DataSourceTransactionManager.

Taken from Spring 3.2 tx-propagation-nested.

The solution I'm proposing to reproduce the case is to use Propagation.REQUIRES_NEW.

According to that.
It seems that the only difference between a REQUIRES_NEW and a Nested is in what happens if the outer transaction does a rollback.
But our outer transaction does not rollback.

I'm going to push a pull request with such kind of test.
The issue could be reopened in the future if someone discovered that is not fixed, providing a test case reproducing the case.

Fabio Massimo ErcoliAugust 21, 2019 at 11:59 AM

I think the same. I'm going to create a test for it.

Yoann RodièreAugust 21, 2019 at 6:56 AM

I think this should be covered by your work on HSEARCH-3360, but the nested transaction thing makes me doubt. In particular, I wonder what happens in this scenario:

  • open transaction A

  • change entities without flushing

  • open nested transaction B

  • change entities

  • flush

  • rollback transaction B (should clear the session?)

  • back to transaction A

  • flush

  • commit

This may not be a valid use of nested transactions, I don't know. I'm mainly wondering what will happen to the changes performed in transaction A...

Emmanuel BernardOctober 3, 2013 at 8:33 AM

I tried to make sense of what you had in mind but that did not work. Can you make a summary.

From what I understood you wanted to:

  • collect all flushed entities (via a flush entity event) and mark them as non clearable

  • collect clear events (from ORM), flush the index work for non clearable entities and clear the queue of the other works

I don't think it makes sense. By definition all entities in the indexing queue are entities that have been flushed one way or the other. And conversely, no entity that have not bee flushed are part of the index queue. So the non clearable collecting business is unnecessary.

Did I incorrectly read what you had in mind?

Fixed

Details

Assignee

Reporter

Original estimate

Time tracking

No time logged1h remaining

Components

Sprint

Fix versions

Priority

Created February 5, 2013 at 11:19 AM
Updated August 23, 2019 at 2:33 PM
Resolved August 22, 2019 at 12:27 PM