Announcement Announcement Module
No announcement yet.
Hibernate provider / writer Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Hibernate provider / writer

    I assume that there is no problem if we implement a dao using hibernate and plug that in on the itemprocessor to persist the items. I'm actually a bit surprised that there isn't a sample that does this as it seems to me that this would be a typical use of spring batch.

    However, and this is where I'm a bit unsure, we are also thinking of writing an itemprovider that makes use of hibernate to provide the objects. Are there perhaps any reasons why this would be a spectacularly bad idea?

  • #2
    hibernate provider / writer

    There is no problem implementing an ItemProvider or ItemProcessor using a HibernateDao but there was some history as to why we didn't use it. We actually tested using Hibernate for a RepositoryDAO and found no issues with it and for us it almost made sense because we are database agnostic.

    There is a little history about why we didn't use Hibernate. There are some on the team that are big Hibernate fans and others that are not. We found that this was represented by our client base as well and those who were against were quite adamant and there is no changing their minds. Rather than fight that battle we based our repository persistence on a minimal persistence.

    In addition , in the versions of Hibernate before Hibernate 3.x there were some major issues to get over in getting Hibernate to perform in a batch environment. We released one of our early java batch architectures on hibernate 2.x and it was very challenging getting it to perform. However, I'm currently using Hibernate 3.2.4.x and there have been many improvements to making batch successful with Hibernate. You should make sure you understand the options. It can be found at The StatelessSession is basically what you had to write with hibernate 2.x batch architectures through using options suggested by Gavin King in one of his blogs about batch (e.g. set FlushMode.NEVER, now called MANUAL, turn off caching, etc.). I have not had a project yet where I have a chance to test out the hibernate batch options but I wouldn't shy away from it either. There are so many other advantages if you happen to buy into the domain driven design and ORM approach, which I do.


    • #3
      hibernate provider / writer

      Thanks for your response. I agree that there are advantages to working with hibernate, which is why I'm considering writing a HqlScrollableInputSource. This inputsource would be similar to the existing SqlCursorInputSource, but configurable through a HQL query and internally using Hibernate's Scrollable to retrieve the next object.

      If an objectgraph becomes a bit more complicated the SQL query for the SqlCursorInputSource will become increasingly cumbersome to write, as will the accompanying FieldSetMapper. In this case it will be much easier to use HqlScrollableInputSource. In addition we should be able to take advantage of Hibernate's lazy loading mechanism which could lead to considerable performance improvements...


      • #4
        I went ahead and created an issue in Jira regarding this:

        I didn't tie it to a particular version, because I don't think it's required for release 1. However, if people feel it's important, please vote on the issue, or feel free to create the input source and add it to the issue as a patch.


        • #5
          I just thought of another provider implementation. In a lot of environments there is already an existing business layer and usually that layer already takes care of persistance and retrieval under the covers. So I think that a provider that delegates the actual retrieval to another component might not be such a bad idea. (You don't want to change your business layer to implement the itemprovider interface)


          • #6
            There could be scenarios where that work, however, you need to carefully analyze the business layer you plan on using before using it in a batch scenario. In many cases it may be designed for online use cases, and do many things that are okay in that scenario, but could perform poorly in a batch scenario.


            • #7
              I have submitted a patch to BATCH-150 containing hibernate input source and a sample job. The implementation is very simple (stateless session + scrollable result set), so I want to encourage those more experienced with hibernate to take a quick look at it and check there's no catch (frankly I'm no hibernate guru).