Announcement Announcement Module
Collapse
No announcement yet.
Setting Hibernate Flush mode in spring Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Setting Hibernate Flush mode in spring

    Hello,

    I am using Hibernate and Spring. Actually i need to set the Hibernate mode to manual. I tried with the following setting in the spring config xml

    <prop key="org.hibernate.FlushMode">MANUAL</prop>

    but when I call the getFlushMode() method on the session, it returns 'AUTO'.

    Please let me know how to set the hibernate flush mode in the spring config xml.

  • #2
    I don't think you can do it in a general way like that. You can set the flush mode on the HibernateInterceptor or on the HibernateTemplate.

    Comment


    • #3
      You shouldn't work with flushing too much since its behavior depends on the queries/database size at runtime.
      If you want to take control however, you can work directly on the hibernate session by using a Hibernate callback for example (besides the hooks that karl already pointed out).

      Comment


      • #4
        Was there any reason you were trying to manually work with the flush mode?

        Comment


        • #5
          Thanks for your interest.

          First answering Karl’s question, when we tried to profile our application as part of performance tuning of our application, we noticed hibernate is calling flush for every hibernate finders.

          We wanted to stop it, as we the business call that we are testing does not include any write operation at all.

          The second thing is that I’m very much new to hibernate and spring. When you’re talking about HibernateInterceptor or HibernateTemplate or Hibernate callback, as not very much sure how to implement it. Can you please point me to some doc or samples using which I can implement it?

          Comment


          • #6
            The flushing does indeed happen before finds, that is the standard behavior. If you changed this there is no way of ensuring what you find isn't stale data! If there is no data to update in the DB then the call to flush shouldn't really cost much.

            http://www.hibernate.org/hib_docs/v3...state-flushing

            How are you using Hibernate and Spring together? Are you using HibernateDaoSupport, HibernateInterceptor?

            Comment


            • #7
              I am not very much sure what is HibernateDaoSupport or HibernateInterceptor, following is the configuration that we have made in the spring config xml.

              <bean id="sessionFactory"
              class="org.springframework.orm.hibernate3.LocalSes sionFactoryBean"
              abstract="false" singleton="true" lazy-init="default"
              autowire="default" dependency-check="default">
              <property name="dataSource">
              <ref bean="dataSource" />
              </property>
              <property name="mappingJarLocations">
              <list>
              <value>hbmapping.jar</value>
              </list>
              </property>

              <property name="hibernateProperties">
              <props>
              <prop key="hibernate.dialect">
              org.hibernate.dialect.OracleDialect
              </prop>
              <!-- prop key="current_session_context_class">thread</prop -->
              <prop key="hibernate.transaction.factory_class">
              org.hibernate.transaction.CMTTransactionFactory
              </prop>
              <prop
              key="hibernate.transaction.manager_lookup_class">
              com.taxware.twe.util.hibernate.GenericTransactionM anagerLookup
              </prop>
              <prop key="hibernate.jdbc.use_streams_for_binary">true</prop>
              <prop key="hibernate.jdbc.batch_size">0</prop>
              </props>
              </property>
              </bean>

              we directly call session.saveorupdate, session.delete, session.getNamedQuery.

              Comment


              • #8
                What you are looking for are classes that extend HibernateDaoSupport, or a bean in the applicationContext that is a HibernateInterceptor. If you don't have any of these and your using Hibernate directly, the flushMode would need be set on the actual Hibernate Session in the code.

                P.S. If you put your code in [ code] [ /code] tags its sooo much easier to read.

                Comment


                • #9
                  Do some profiling and then closely look at the Hibernate in-memory objects and you'll see why flushing occurs. The finders, especially if they take into account dirty tables, force a flush since hibernate doesn't do any in memory locking so it has to first synchronize its state with the database to make sure the finders do not return stale data.
                  If you prevent the flushing, you might very well add in, incorrect behavior in your app.

                  Comment


                  • #10
                    I competely agree with Costin! Hiberate is pretty clever, if there is nothing to do I'm sure it won't hit the database.

                    I've also seen people try to do what your doing by playing with the flushMode to *try* and improve performance. After weeks of fixing various bugs and code hacks, the code was reverted to let Hibernate manage this. It actually did a more efficient job and more importantly, it worked!

                    Comment


                    • #11
                      As a side note, if you want to improve performance look closely on how caching works and start adding it to the application since depending on your use case, it might improve performance significantly.
                      Synchronization with the database is the correct behavior - if you prevent it, you don't optimize but rather cripple your application. However, cache can still preserve the application semantics but avoid the 'expensive' trips to the database.

                      Comment


                      • #12
                        Dredging up an old conversation.... I've got a couple of comments:

                        - what you are calling "stale data" can be considered to be "repeatable reads" by other people. That is, it's often a good thing to get the same data over and over again within the context of a session, even if it's changed somewhere else.

                        - Why even have a first level cache if you strongly discourage anybody from using behavior that would make use of it?

                        Comment


                        • #13
                          Originally posted by imanewbie View Post
                          Dredging up an old conversation.... I've got a couple of comments:

                          - what you are calling "stale data" can be considered to be "repeatable reads" by other people. That is, it's often a good thing to get the same data over and over again within the context of a session, even if it's changed somewhere else.

                          - Why even have a first level cache if you strongly discourage anybody from using behavior that would make use of it?
                          I've never heard of a use case that requires stale data in a high tx system.

                          1st level cache (persistence context) is required to perform automatic dirty checking. I don't see how anybody is discouraging use of it here....

                          hibernate.org/hib_docs/reference/en/html_single/#objectstate-flushing

                          Except when you explicity flush(), there are absolutely no guarantees about when the Session executes the JDBC calls, only the order in which they are executed. However, Hibernate does guarantee that the Query.list(..) will never return stale data; nor will they return the wrong data.

                          It is possible to change the default behavior so that flush occurs less frequently. The FlushMode class defines three different modes: only flush at commit time (and only when the Hibernate Transaction API is used), flush automatically using the explained routine, or never flush unless flush() is called explicitly. The last mode is useful for long running units of work, where a Session is kept open and disconnected for a long time (see Section 11.3.2, “Extended session and automatic versioning”).

                          Comment


                          • #14
                            Originally posted by Costin Leau View Post
                            As a side note, if you want to improve performance look closely on how caching works and start adding it to the application since depending on your use case, it might improve performance significantly.
                            Are you referring to Hibernate 2nd level cache? If so, this is only true for entities that are used for mostly (or only) read scenarios, no?

                            Comment

                            Working...
                            X