1

we're facing a very confusing issue in our application which is designed as 3 tier application using * Spring-Data JPA (1.8.2.RELEASE), Hibernate (4.3.10.Final) in data layer * Spring managed Pojos (@Service beans) in service layer * Wicket (7.2.0) in GUI layer

I know and I'm aware of the problems that might arise when using JPA managed beans in GUI layer (Lazy loading, equals, hashcode etc). To get rid of that we use Wickets LoadableDetachableModels to reload every single entity during each request.

Now we have a page where the user can select an entity within a tree. Entity is encapsulated within a LoadableDetachableModel as mentioned. This entity has a 1:n relation to another entity. When selecting the entity via tree, the 1:n relation is beeing accessed leading to the well known org.hibernate.LazyInitializationException: failed to lazily initialize a collection of role: com.isb.bppm.wm.model.Product.children, could not initialize proxy - no Session exception.

This is very confusing, since this only occurs when configuring DB2 as database. For local development we're using in memory apache derby where the same code doesn't lead to the mentioned exception. My analysis so far leaves the database as only difference between the two configurations. Let me further mention, that we use Springs OpenEntityManagerInViewFilter for every request, so the situation where no session is open should never occur.

Has anybody of you faced similar issues and can give us a hint what might got wrong?

Improve this question
2
  • 3
    Very hard to help an (even very basic) example. Are you sure that every LoadableDetachableModel is correctly detached? Either by passing it to a standard wicket component or by detaching in the onDetach() method
    – Thorsten Wendelmuth
    Commented Aug 26, 2016 at 10:11
  • I will check that on monday. Thank you for the hint. By now I would guess that the models are all set via setDefautModel(). Will comment on that monday
    – Ansgar Schulte
    Commented Aug 27, 2016 at 13:53

1 Answer 1

Reset to default
0

Thanks to Thorsten I checked our code for models which are not properly detached. And indeed this was the correct hint. Our own implmentation of LoadableDetachableModel used equals and hashcode just like org.apache.wicket.model.Model does. This caused the model object to be attached just after detaching it, since the logger saying that modelobject was detached used hashcode of model within the log comment.

Fixed this by implementing equals and hashcode by checking the entity ID which is member of our loadableDetachableModel implementation. This servers well for us, since the ID is guaranteed to not be null and unique of course.

Anyway the question still remains why only changing the database connection uncovered this issue?

Improve this answer
1
  • Well I did investigate this issue back in 2009/10 in Wicket 1.4. Potential differences: deployment/development mode; serialization strategy; different webcontainer? Specially when developing locally we rarely saw those errors as well... I think it had something todo with them not really being serialized/deserialized, plus the Thread was maybe the same for hibernate ... but I would need to look into it again. We solved that issue by adding it to our coding guidelines and making everybody aware of the potential issues (so it's also checked during code review)
    – Thorsten Wendelmuth
    Commented Aug 29, 2016 at 11:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.