Vivek . Nair wrote:Is large session size , a big bottle neck ?
Regardless of scalability, Modelling your application using the session as a storage area is something that should always really be avoided if possible in my opinion.
Although it is always an easy option to hold data within a session, there are always other options to keeping data persisted across sessions, without having to use the session for potentially large amounts of data.
Regards, Dave Brown
SCJP 6 - [url]http://www.dbws.net/[/url] - Check out Grails Forum
Vivek, you have some lint in your display name, so could you please clean it up?
I'll be better able to tell you about scalability in a couple of weeks as I ramp up an app that's intended to serve a lot of users. I've used JSF in production multiple times, but never for high-volume apps before.
While I do have some misgivings about server-side storage requirements, my bigger concerns are about the relatively large quantities of data that get passed back and forth in a JSF conversation and in the CPU resources requires to set up and tear down FacesContexts for each one.
Fortunately, JSF isn't an exclusionary framework, so if I determine that parts of the system can't sustain that sort of load, I can convert them to Struts - or raw JSPs - on an as-needed basis.
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: Mar 06, 2009
I was particularly concerned about complete client side rendered tree and it state in session along with data , it seems like it can become too heavy . and what will be the result when no of user's increases.
is my concern right ?
I have started working in web application recently ..... and have worked mostly on JSF .
Can some one throw light , how other framework handle session ?
The term "session" in JEE is normally reserved for a very specific meaning, and in that context, JSF and non-JSF are mostly the same, although JSF has made me use more session objects than I would have because it wants to be able to navigate more freely, and the only longer-term memory a JEE appserver has outside of actual persistent store is application and session scope objects.
I think you're more referring to state. In JSF, state can be maintained client-side or server-side. You select which in the web.xml.
Client-side removes the need for server-side storage by distributing state amongst the clients. However, you pay for it because the state is sent back and forth to the server as part of the conversation. It's also more susceptible to security issues.
Server-side gets rid of a lot of the network and serialization overhead, but the cost there is that it requires more server-side storage.
Joined: Mar 06, 2009
i have been using server side in web.xml .
went for it , because of the same reason as you stated , will minimize the n/w overhead in one side ( client to server ) .
what did you went for in your application , you built ?