Announcement Announcement Module
Collapse
No announcement yet.
HibernateItemWriter lazy loading problem Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    It's good to get your suggestions, but I'm not very keen yet on any of them for the framework to be honest. The best advice for general purpose use is still (as I said before) not to use Hibernate for reading items at all. If you do use it, you would be advised also to not use objects with lazy loaded properties. The reason for this is the same as the reason why we don't use the main transactional session for the cursor: the contract for ItemReader is forward only, so if you have any errors you cannot use retry or skip if your downstream code relies on the items being attached to the current session. If you have used code like you posted above successfully, that's great, and if you can integrate it with the framework and prove that it works we can certainly take a closer look (use github and pull requests together with JIRA for tracking -see the README in the source code for details). In my opinion it doesn't feel sufficiently general to make it into the framework, where things are complicated enough if you want to use Hibernate already, and we don't really want to make it any more difficult.

    Comment


    • #17
      Originally posted by Dave Syer View Post
      It's good to get your suggestions, but I'm not very keen yet on any of them for the framework to be honest. The best advice for general purpose use is still (as I said before) not to use Hibernate for reading items at all. If you do use it, you would be advised also to not use objects with lazy loaded properties. The reason for this is the same as the reason why we don't use the main transactional session for the cursor: the contract for ItemReader is forward only, so if you have any errors you cannot use retry or skip if your downstream code relies on the items being attached to the current session. If you have used code like you posted above successfully, that's great, and if you can integrate it with the framework and prove that it works we can certainly take a closer look (use github and pull requests together with JIRA for tracking -see the README in the source code for details). In my opinion it doesn't feel sufficiently general to make it into the framework, where things are complicated enough if you want to use Hibernate already, and we don't really want to make it any more difficult.
      Dave, thanks for your comments.

      I still can't completely understand, what you want to underline when you mentioned the forward-only contract for ItemReader and Hibernate session. Let's assume that reader does not cause the exception, but the exception was caused by writer. The reader cannot be scrolled back, so the only item that can be used is one in Hibernate cache (it is the same that Batch framework holds). What are the framework expectations, that contradict with 1st approach?

      Also I tried to find any code that tries to remember the reader position and then restore it in case of exception (basically, the reader should be re-opened). This is the only way out for JDBC cursors...

      Actually after thinking a bit (sometimes I do so ) I have realized that the 1st approach will not work if the exception occurs in the writer. In this case the transaction is rolled back and Hibernate session is closed, so the reader should re-open the session in this case. Better say it should not rely on initialized flag but check if the session is opened and reopen it if necessary.

      The 2nd approach is absolutely "legal". Of course, it should not replace HibernateCursorItemReader but extend it with new functionality. I am ready to do all integration work, if you are in position of including it into framework (right now I feel like you are rather not willing to).

      Comment

      Working...
      X