Announcement Announcement Module
No announcement yet.
JobExecutionContext + Hibernate + lazy loading = huge JobExecutionContext serialized Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • JobExecutionContext + Hibernate + lazy loading = huge JobExecutionContext serialized

    Using Spring-batch 2.1.2 and Hibernate 3.2.5.

    I've a first step loading an Entity from Hibernate (for business logic). This Entity is used all along the job as it is involved in business logic.
    So I've decided to put it in the JobExecutionContext.

    Unfortunately this Entity has some Lazy loaded dependencies that I do not use in the business logic (I only work with a few of them). This lead me to the Exception below.

    I encounter a trouble with JobExecutionContext serialization (done with XStream)
     com.thoughtworks.xstream.converters.ConversionException: Cannot handle CGLIB enhanced proxies with multiple callbacks
    This is related to lazy loading ... but lazy loading is fine for me.

    Moreover, this exception reveals that the serialization of the JobExecutionContext causes lazy loaded dependencies to be loaded. This is done in order to serialize the full Entity graph (I assume).
    But according to me this could be an issue :
    Of course, I do not want to have a copy of my database into the serialized datas of the JobExecutionContext.

    Is there a way to filter/customise the JobExecutionContext serialization process in order to avoid serialization of the full Entity graph (I mean all dependencies)?

    I'm looking for something like the options below :
    Option 1 : For example a closer integration between Spring-Batch and Hibernate (regarding JobExecutionContext serialisation) may only serialize the Entity to something repersenting the primary key and Entity type.

    Option 2 : Or a rather simple way may just ignore data of various types (configured in a Spring context way) so we could avoid having the whole Entity graph serialized

  • #2
    Wouldn't it be simpler and more reliable just to store the primary key in the ExecutionContext?