Uploaded image for project: 'Spring Framework'
  1. Spring Framework
  2. SPR-9480

Hibernate 4 smart flushing does not work unless CMTTransactionFactory is being specified

    Details

      Description

      Overview

      There seems yet again another issue when using the Spring 3.1 - Hibernate4(.1.3) integration.

      This issue pops up so late since it only occurs in special circumstances: it has to do with the hibernate "smart" flushing which is not working.

      Hibernate guarantees that every modification you make (CUD) is flushed to the database prior any other operation that can possibly be related to the outstanding queries. This is to ensure that you don't work with stale data within the same transaction.

      For example:

      1. Save an entity
      2. Update the property of an entity
      3. Query the entity using the value of the property changed in the previous step in the where clause

      Hibernate will make sure that the changes by step2 (and possibly also the insert of step1 - if not done already) are flushed before step3 is executed (smart flush). If this didn't happen we would never be able to retrieve the entity in step3.

      The problem is that this smart flushing is not happening any more, since Hibernate does not detect that it is in a transaction.

      Taken from SessionImpl L1178:

      protected boolean autoFlushIfRequired(Set querySpaces) throws HibernateException {
      		errorIfClosed();
      		if ( ! isTransactionInProgress() ) {
      			// do not auto-flush while outside a transaction
      			return false;
      		}
      		AutoFlushEvent event = new AutoFlushEvent( querySpaces, this );
      		for ( AutoFlushEventListener listener : listeners( EventType.AUTO_FLUSH ) ) {
      			listener.onAutoFlush( event );
      		}
      		return event.isFlushRequired();
      	}
      

      What happens is before step3 is excecuted 'autoFlushIfRequired' is called (good). However isTransactionInProgress() will returns false. If you drill down in the code, you will see that it will call: transactionCoordinator.isTransactionInProgress() which will then call getTransaction().isActive(), which delegates to JtaTransaction L237:

      	@Override
      	public boolean isActive() throws HibernateException {
      		if ( getLocalStatus() != LocalStatus.ACTIVE ) {
      			return false;
      		}
      
      		final int status;
      		try {
      			status = userTransaction.getStatus();
      		}
      		catch ( SystemException se ) {
      			throw new TransactionException( "Could not determine transaction status: ", se );
      		}
      		return JtaStatusHelper.isActive( status );
      	}
      

      The LocalStatus will be "NOT_ACTIVE" and the userTransaction is null. Why? Because no one called "begin" on the JtaTransaction.

      In case of the HibernateTransactionManager it will call begin() once a transaction is started (in that case it will be JdbcTransaction rather then JtaTransaction).

      So while there is a transaction started and everything is working nicely there is still a part of Hibernate which is unaware that a transaction is indeed active, which results in strange behavior like illustrated here. Note that everything else is working OK, the session will get flushed before transaction completion and everything will be in the database.

      However, within the transactions we now have a stale data problem. AFAIK this is a bug in the integration, since there are no more secret properties we can use to fix this one on hibernate level.


      Examples

      I supplied again 2 sample applications, one with hibernate3 and the same with hibernate4 to illustrate the issue.

      You can deploy the apps under context root hibernate3/hibernate4 and then point the browser to http://<host>:<port>/hibernate3/Persist or http://<host>:<port>/hibernate4/Persist.

      The Servlet looks up a bean from the application context. It will then call two transactional methods on the bean.

      Method 1
      • Start transaction 1
      • Save an entity of type 'TestEntity'
      • Change the property 'value' to literal 'SomeValue' on the saved entity
      • Perform a query which selects all entities of type 'TestEntity' where their 'value' property matches 'SomeValue'
      • return result
      • display result
      • End transaction 1
      Method 2
      • Start transaction 2
      • Perform a query which selects all entities of type 'TestEntity' where their 'value' property matches 'SomeValue'
      • return result
      • display result
      • End transaction 2

      With hibernate3 you will see this output:

      Saving... Done.
      Result from read in TX: 1 Value:SomeValue
      Read from table in separate TX: 1 Value:SomeValue

      Which means that both in the same transaction and in the new transaction the data was found in database after saving/updating.

      In hibernate4 however:

      Saving... Done.
      Result from read in TX:
      Read from table in separate TX: 1 Value:SomeValue

      You see that in the same transaction the query did not return any results in the second output line. This is because the save of the entity and/or the update of the property where not flushed to database prior executing the query.

      Note: in the output we show two properties of the 'TestEntity'.

      • The value '1' in the output is the value of the 'id' property which is the PK of the entity and auto-increment.
      • 'SomeValue' is the literal value we assigned to the 'value' property of the entity after we saved the entity.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                juergen.hoeller Juergen Hoeller
                Reporter:
                koen.serneels Koen Serneels
                Last updater:
                Juergen Hoeller
              • Votes:
                5 Vote for this issue
                Watchers:
                8 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Days since last comment:
                  5 years, 47 weeks ago