Hi Guys

I get the infamous LaxyInitiatlizationException though I use the OpenSessionInViewFilter. To explain the scenario I have snippets of the code/entities and the platform specifics.

We use the following Hibernate:

3.4.0.GA - hibernate-Annotations
3.4.1.GA - hiberate-Core
3.6.0.GA- javassist
2.5.6 - Spring


Use Case:

1. I Look up a list of Subjects that invokes a Service Layer that calls the DAO which uses HSQL to build the query and return a List<Subjects>, the DAO gains access to the session via a Factory getSession() and executes the query, this returns a List of LinkSubjectStudy entities

2. The List is rendered in Wicket using the PageableListView, the list view is of type Person
3. I then list the Phones linked to the Person using the association, When i navigate the list Of person.phones, I intermittently get the LaxyInitializationException

The web application uses Wicket and the application is configured with


These are my entity classes


Would be great to hear your suggestions.



Thanks
Niv

Hi Niv;

i got the same problem.for testing purpose only comment out the code
session.close() and run the code.only for testing .

thanks

Rajesh
Thank you for the time. I do not explicitly issue a session.close in the lookup method via the DAO. Since this is going to be handled via the OpenSessionInViewFilter.
So as such my code does the retrieval and returns a List<SubjectVO> to the caller. As per OSVF pattern, once the UI is rendered that should close the session bound to the request thread.

Correct me if i am wrong.

Cheers
Niv

Hi Niv,

We are also having the same issue, did you find any solution for this.

Thanks
Rajeev

Hi!

The OpenSessionInView pattern only guarantees that the session is open during one single thread execution.
When the page has been rendered and has been returned to the browser, the session gets closed by the filter.
So subsequent requests (e.g. navigation request) require another new session which will be opened by the OpenSessionInViewFilter. But as the "old" person object is not connected to the "new" session, it is considered as disconnected object which's references cannot be loaded lazily.

Hi Guys,
Thanks for the response.

@Rajeev - Not yet mate am still looking at the issue when I do will update this post or if you get any answers would be good to learn from that. I also seem to be getting a related exception now, not sure if this is a related one as yet will describe it in a moment. Just a quick one, would like to know what framework your using for UI Wicket?

@Winterer: - I think you have a strong point there. That was my understanding that once it renders OSVF closes the session that is correct, however when we navigate on the front end at present I do not load the entities from the back-end instead I resort to pulling that information from the Model class in wicket .i.e a Value Object that contains the result set that was fetched. It make sense in my use case that I don't want to pull it from backend here just as yet, will explain why later but yeah I see your point there, .i.e the child association will not be able to get the values..however, since I manually have iterated/initialised it the VO should still have those values isn't it?

Now here is something I noticed with some changes.

Refer to the Person class it contains a Collection of Phone i.e Set<Phone>, the Phone entity has a PhoneType entity that is mapped as @ManyToOne like so:



On the front end I commented out the code that renders the PhoneType as part of the Phone Listing and the Java code equivalent in Wicket.
Now when I run, there is no LazyInitializationException, that kinda stumps me. So since the Set<Phone> was initialized manually in the backend DAO by iterating the collection and setting it into an ArrayList, it has initialized it.
However, the Phone.PhoneType seems to throw this exception and guessing this is/was the object that has caused this issue.

Now given that I have commented all this out and navigating the Phones does not throw LIE, I now noticed that after sometime I repeat a search operation by canceling from the Detail Page/Panel. When i clicked on the Search button I got a ( please bear with me).



I guess for some reason the backend or the connection has dropped, or has the program forced it to drop the connection by not having enough resource? Don't know why this is occuring. The other part is...having to fetch from backeend for each navigation and render the phoneType.

Thanks again let you know how it goes
Cheers

Hi Guys,
I did a fetch each time the user navigated on the List instead on relying on the Model/VO's list of Phones. Since this is being fetched from backend, I don't get the LIE anymore.
This goes along with what Winterer mentioned.

Although doing so is a hit on the database for every page navigation I need to see how to optimise this. However I think this occurs only when the PhoneType is being fetched that LIE occurs. I have to work around away to do this. But yeah for some reason the initial fetch list that contained the Phone.PhoneType seemed to be creating the issue.

Anyways thanks guys for the time, bounce and let me know how u went Rakesh.

Cheers
Niv

Hi Rakesh and Rajeev,

One of the things I learnt from this issue is that when a collection is initialized, their associated properties don't automatically get values, I think its some proxy object that gets initialized. Must read the manual or look at the forum topics for specifics.

In my case,

public class Person {

String firstName;
Set<Phone> phones;
}

public class Phone{
String phoneNumber;
PhoneType phoneType;
}

Here, when the Person.phones is initialized either manually or by calling Hibernate.initialise(), the child of Phone, PhoneType is not initialised or even if it does, PhoneType's attributes are not e.g PhoneType.Name/Description.
So when the UI rendered it, for the first 5 Items, OSVF had the session available so the UI rendered the Phone information and the Phonetype. Once it rendered it closed the session.

When user navigates to another page, The top level items are rendered no problem when it came to Child of Phone, PhoneType, it will cause this issue.

Solution:
1. For each navigation, do a call to back end in your pagination logic or
2. Explicitly initialize the sub-child object that is required if you think it makes sense and is not much of a performance hit. This resolves it as well.

Hope this helps, any further pointers most appreciated

Cheers

Niv,

usually it's absolutely ok to hit the database on every navigation; otherwise you might render stale (e.g. already deleted or updated) objects. Performance should be no problem in most of the cases as long as your mapping is clever enough to not prefetch too much unnecessary data (e.g. via EAGER assiziations).

If you really want to keep objects for multiple requests, have a look at the session-per-conversation pattern (http://community.jboss.org/wiki/OpenSessioninView#What_about_the_extended_Session_pattern_for_long_Conversations). Note that keeping a session over multiple requests comes with two major penalties (in my point of view):
(1) You introduce server state (negative impact on scalability)
(2) You have to define and maintain your conversations (when does a conversation start, when does it end), and do proper cleanup of your server state.

Mario.

Mario,

I agree it makes sense to fetch from back end for every page navigation to keep data as fresh/current as possible.Although it(a record) can still be removed/updated from the time it was rendered after the fetch.But is a lot safer, I suppose.

I only use LAZY and not EAGER so that is what we want. I will have a read at the link, think I did a while ago but session per request would be optimal.

Mmm good thoughts thanks for taking the time. Until next time
Cheers
Niv

Hi Niv,

We are using JSF (Icefaces) as a web layer framework. The solution which you mentioned, we also tried that and works good, so probably we would be doing the same i.e. initializing the child object on demand by calling the DAO and initializing that particular child collection.

Thanks
-Rajeev

Hi Ravjeev,

Glad that helped. Hitting the backend when the user requests it would be lot safer, am guessing that is what you meant by on-demand, however you do not have to initialise the child objects explicitly. Not sure why you want to do that if your accessing the data base on-demand. Can you explain why you want to

1. Invoke DAO to access data on-demand
2. As part of that why are you initialising the child objects.

You don't have to do #2 because OSV will have the session open until the UI (JSF) renders the page. Depends on what your usage is can you explain.

Cheers
Niv