Hi all,

JSF advocates session scoping of its managed beans as this gives the webapp stateful behaviour, which ofcourse would be nice, and save us from a lot plumbing that was needed in the Struts age.

To be able to get all these nice things, developers are required to be able to put Hibernate-managed pojo's in httpsession scope, without running into LazyInitialization problems.

So I went looking on the net for documentation. I found several suggestions, like using session-per-session but none striked me as the way I would want to go, at least not before posting this question.

Would it be possible to use some kind of hibernate/jsf integration tool (maybe a servlet filter) that would allow for the following:

1. Be able to keep using session-per-request and the open-session-in-view filter

2. Automagically reattach any hibernate managed pojo to the new session that is in use by a session-scoped JSF component (ofcourse this would have to happen very early in the lifetime of a request)


Would the above be possible and architecturally correct? If so, does such a piece of software already exist?

-- Hans

If you dare to use something very advanced, but is still in beta I would take a look at seam.

http://www.jboss.com/products/seam

You get a lot for free, even workspace management, transactions,
a very simple to use bean management - just annotate the classes
and off you go, no xml bean definition necessary etc...

The only drawback is that you will have to use at least the jboss microcontainer or a different application server.

You don't really need to do that. You can simply let the entities go in a detached state (and managed by jsf) .. And afterwards merge them back into managed state...

I use a simple transaction filter per request and this also avoids lazyinitialization problems... Hibernate uses

web.xml


persistence.xml

Hello Tim,

I'm affraid your solution is not applicable for me because I am using Spring to handle my transactions. I will take a look at that filters sourcecode for ideas though..

I just skimmed the posts but I think what you're describing is exactly Springs OpenSessionInViewInterceptor which will neatly bind a session per request. I notice your using AOP to manage your TX's - why not use it for your sessions too?

A good article on it here http://www.jroller.com/page/kbaum/20050406

Try to test it using some load testing tool.

Hi Tim R,

I am familiar with the OpenSessionInViewFilter and I am already using it. I think you did not understand my problem. The problem is that my domain pojo's get disconnected from their hibernate session after each request and I don't know of a way of reattaching them automatically at the beginning of each subsequent request in the http session.

Hello baliukas,



You mean that the memory usage will be ridiculously high due to storing too many objects in the session? I absolutely agree that this is a problem. Storing state at the clientside is not an option either, i find it amazing that the JSF-people even specified this.

But do you still think that storing pojos in the httpsession is not an option even if I'm not expecting many (not more than let's say 5) concurrent sessions? Can you suggest an alternative?

It depends on scalability requarements. Seam must help too, BPM must manage state without problems (workflow stuff is designed for state management in mutitranasaction process, process can be multiuser too).
I have no test, but I am afraid plain JSF ( any stefull web framework) can not manage persistent state (stefull UI stuff and components must not be a problem).

BTW, there is no problems to fake session scoping in http session wrapper


Object getAttrubute(String name){
return load(session.getAttrubute(name));
}

void setAttribute (String name,Object value){

session(name,getId(value));

}

Hmm yes but I don't think I can hook that kind of code into JSF. Right now i'm thinking of writing a PhaseListener that looks for http session-scoped hibernate pojos in the JSF 'restore view' phase and reattaches them

I took some time to read some sourcecode from Seam, and from what I can make out of it right now, Seam uses a similar strategy.

regards,
hans

You can wrapp http session in filter for any framework (if framework doe's not cast wrappers ).

Reattached entity is stale (or you must reload it anyway), probably it works for specific use cases (non transactional data), but it is a wrong assumption.

You must synchronize you code to store data in http session directly (it is not thread safe) and forget about clustering.

Clustering - yes, but in a lot of situations I will just stick with a load balancer that simply assigns users sessions to a machine. If users lose a session, too bad.

Stale data worries me a lot more. Are you basically saying that I shouldn't try to put pojos in the http session at all, i.e. let every JSF managed-bean be request-scoped. That would be a pitty, but alas...

"Optimistic locking" can be used in some cases to solve this issue (to detect write conflict)