Announcement Announcement Module
No announcement yet.
hibernateTemplate generates too much sql queries on a find Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • hibernateTemplate generates too much sql queries on a find

    Hi all,

    I use the HibernateTemplate to execute a query defined in my hibernate xml definition. The query is about a parent and 2 children collections.

    Here is the query :
                from Project project
                left join fetch project.components
                left join fetch project.versions
    The first sql query logued by hibernate is good. But 2 more select queries are executed due to the HibernateTemplate call on flushIfNecessary.

    I think the template shouldn't call a flush for a query as we are not modifying any persistent data.

    What do you think?

  • #2
    You can change the flush mode on the template to suite yourself.

    However, the normal auto mode is very appropriate. Flush will be called if the template is actually about the close the Session. So if you have a wrapping transaction with thread-bound Session synchronized to that transaction, only when the Session actually gets closed with the tx completion do you get a flush...


    • #3
      Thanks for your quick answer.

      I changed my code to disable the automatic flush :

      HibernateTemplate hibernateTemplate = getHibernateTemplate();
      List undistinctList =  hibernateTemplate.findByNamedQuery("projectByUser", userLogin);
      But it doesn't work. I still have some hibernate queries at the commit of the Tx (I use a TransactionInterceptor to do declarative Tx management). I looked at the HibernateTemplate code and I found this in the execute Method :
      if (!existingTransaction && getFlushMode() == FLUSH_NEVER) {
      I don't understand why you can't set the flush mode to never if you use a tx.




      • #4
        To give some more details.

        I want to send a subgraph of my domain objects on a swing client. I use declarative tx declaration around the server methods calls. The whole graph can be quite important and so I use lazy initialisation.

        I just want to define the size of the graph for particular unit of work. In that precise case the hibernate use is only for retrieving read only data. I have to initialize 2 child collections before sending the result to the client.

        If I put this call in a transaction : it works but I have unecessary select queries at the tx commit.

        If I don't use the transaction : the initialization of the collections fails.

        What can I do?



        • #5
          flushIfNecessary() seems definitely broken --

          FLUSH_COMMIT mode doesn't work at all like supposed to.
          - it behaves like a 'FLUSH_EAGER'.

          FLUSH_NEVER sets the Session that way also; prevents your explicit Tx.Commit() from flushing anything; thus typically nothing saved.
          - explicit State Changes, should not be blocked by implicit settings!
          - this area is rather too costly to debug.

          we note that in other threads where there was a good answer, Costin pops up quite quickly with a response... and he's thoroughly absent from this one.

          conclusion: HibernateAccessor. flushIfNecessary() is broken or significantly
          flawed in design. i'll file a JIRA report also.

          Cheers, T


          • #6
            we note that in other threads where there was a good answer, Costin pops up quite quickly with a response... and he's thoroughly absent from this one.
            This thread is from 2004, months before I actually joined the forum (in 2005).

            Coming back to the thread, flushing hides some very subtle semantics and in most cases it should be handled by the framework. Flushing also depends on whether you are running inside a transaction or not.
            What do you expect from the flushing mode and does not happen?

            One thing about FLUSH_NEVER - it is used when doing transactions which means that only the database is not synchronized which really doesn't matter since you are anyway running inside a transaction so the other running transactions are isolated from your changes (ofc, depends on your settings).
            However, your changes can be seen in the session they are made.