Are there any state saving method that would allow JSF application to intially save state data on server but after the session expire time interval , that state is transferred to client so that app is always responsive even after the session timeout on the server & memory is better managed on server?
Or any way this could be implemented? But I expect that this should be a part of the JSF specification !
Edit
After suggestion by BalusC, I'm highly impressed with the Stateless JSF principles & the current implementation for it. If anyone else here is also interested in stateless JSF being added to the JSF spec, consider having a look at or voting this issue.
Stateless JSF offers huge performance boosts for some payoffs like inability to create views dynamically (e.g. by binding, JSTL tags, etc), or modifying it.
A Stateless JSF operation mode
would be incredibly useful for high-load applications and
architectures:
https://web.archive.org/web/20140626062226/http://industrieit.com/blog/2011/11/stateless-jsf-high-performance-zero-per-request-memory-overhead/#comment-4
This has previously been suggested by Jacob:
http://weblogs.java.net/blog/jhook/archive/2006/01/experiment_goin.html
This would help JSF ditch the stigma of "slow and memory hog," and
help keep up with current tech trends (stateless architectures.)
How is that technically possible? The server can never reliably predict beforehand if the next request would create a new session and thus the response of the current request has to use client side state saving instead of server side state saving. If you ever succeed to implement it using plain JSP/Servlet, feel free to post a JSF specification enhancement request.
Just use client side state saving and make sure that partial state saving is enabled. The overhead is relatively minor as compared to full state saving.
Note that it's possible to use JSF entirely stateless. See also this blog. The only major payoff is that you can't create views dynamically (e.g. by binding, JSTL tags, etc), nor manipulate it after creation (e.g. by adding/removing component's children).
See also:
Why JSF saves the state of UI components on server?
Related
I am building a rich app on GAE using Canoo's RIA Suite. This package splits Java Swing components into server-side and client-side parts. On the server, it looks like a 'desktop' Java application. The client keeps its own map between these halves. When GAE starts a new instance, the client-side parts don't know about it -- if the next request they send is routed to the wrong instance bad things happen.
I figure I could get around this problem if I did one of two things:
Forced a GAE instance to serve exactly one HTTP session.
Directed each HTTP request to a specific GAE instance.
My question is, in the GAE environment, can either of these be done?
Neither of these two options will solve your problem, because an App Engine instance can die and be replaced at any moment.
If you can save a state of your server-side "half" in a datastore, you can load it when a request hits the "wrong" instance, but it's probably not a very efficient solution.
You may be better off using a Compute Engine instance.
I agree that neither of those two options will work for you. The implication of your current design is that you are storing state in memory on an instance, which will not work with GAE (or any autoscaling distributed system). You should put any state into some distributed data store, whether that is memcache (which is volatile), the datastore or cloudSQL
GAE/J has built in support for java sessions, the session state is persisted in the datastore across requests so that it is valid on any instance. For this to work, everything stored in your session will need to be serializable.
You can enable this by following these instructions.
Otherwise you can manage persisting server state yourself into the datastore accelerated by memcache, and linking it to a 'session' with a cookie. If you go down this road make sure you understand the implications of eventual consistency in the GAE datastore.
Does spring web flow used widely in industry for a conversational flow behavioral application or a wizard kind of application. The main purpose of going such application is to reduced the data we need to keep in session right? Does it worth to go for a framework such as web flow or else what would be other industry standard implementation for such enterprise application?
Below are the disadvantages of a normal implementation contrast to spring web flow which Spring claims,
Visualizing the flow is very difficult.
The application has a lot of code accessing the HTTP session.
Enforcing controlled navigation is important but not possible.
Proper browser back button support seems unattainable.
Browser and server get out of sync with "Back" button use.
Multiple browser tabs causes concurrency issues with HTTP session data.
If you have any feature in your website that has more steps than filling up a form and submit I would definitely go for spring webflow.
Webflow still use the session to store the data, but abstracts everything for you and also does the cleanup on the session when the flow is finished.
You can have as many simultaneous 'instances' of a flow as you want. Think about creating a flow for buying securities, as soon as you click buy, a separate context for that transaction is created, and you can go on as many steps you want (adding a value, checking limits etc) in both of them with complete isolation of state.
The flow xml file is easy to understand and is very manageable as the flow grows with more features.
The whole structure for unit testing the methods on the flow is also pretty easy to mock, which is a huge plus on top of dealing with mocked session objects on a traditional controller. (http://vishwanathk.wordpress.com/2011/07/12/using-mockito-to-unit-test-spring-webflow/)
Give it a try, at first you'll tell yourself several times, "Oh I should have just coded a controller and a few action mappings. But after understanding how the webflow works, you'll never going to code more than 1 step on traditional controllers.
I heard a web application should be as stateless as possible. But it seems to me very hard to realize this often. For instance, what if I:
Process a request
Redirect the user to the start page
Want to display the result of the request?
If the result is a little bit more complex, then just a string which could be passed as a parameter (or I don't want to include that information via URL), then I cannot combine 2. and 3.
The only solution I can think of here is keeping the information as states in the Java program.
But that would break with the rule of a stateles web application, wouldn't it?
I heard a web application should be as stateless as possible
What? There is state everywhere in a web app, both in the client and on the server. Frameworks like Sproutcore/Ember even have components called State Managers to manage, um, the state.
The server maintains some state in a user's session (typically).
Did you hear that HTTP is stateless? That's another story, and completely true. Also, it can be a good idea to write server side components that don't share state, due to threading concerns. But neither of those points should be taken to imply that your application doesn't have state.
I recently watched several Google I/O videos where Google developers present GWT with respect to performance and security. In that video the speaker makes mention of several GWT-isms:
Client-side request "batching"
"Disposability"
The pursuit of GWT app "statelessness"
With respect to "batching" it seems like GWT can be configured to queue-up server-side RPC calls and send them all at once (instead of many tiny, performance-hindering calls). Unfortunately, I'm just not seeing the forest through the trees here: doe GWT handle batching for you, or do you have to write the logic that performs this bundling/batching? If you have to do it, what kinds of calls can/should be bundled? How do you know when its time to fire the batch off?
In GWT lingo, what does it mean when someone says:
"Clients and servers are disposable"; but
"Views" are not disposable
How does this concept of "batching" and "disposability" relate to GWT app "statelessness". By that, the speaker defined statelessness as:
Browser embodies the session (?!?!)
Server is stateless - except for caching (?!?!)
Client never notices a restart (?!?!)
If someone could help give me concrete understanding of these 3 items and how they relate to each other I think I'll start to "get gwt". Thanks in advance!
doe GWT handle batching for you, or do you have to write the logic that performs this bundling/batching? If you have to do it, what kinds of calls can/should be bundled? How do you know when its time to fire the batch off?
GWT-RPC has no batching mechanism. You can (relatively) easily add some by queueing "commands" in a list and then sending the list as a single GWT-RPC call. Some projects should do that for you with minimal effort (GWT-Platform for example).
RequestFactory on the other hand has batching built-in: you create a RequestContext instance and batch calls to it until you fire() it.
"Clients and servers are disposable"; but "Views" are not disposable
The first is related to statelessness (and, for example, with AppEngine, you don't control when a new server instance is created, shutdown or restarted: the server can disappear at any time, so don't keep state in memory).
The second is about performance: everything related to the DOM in the browser is slow, so constructing a new view (widgets stacked together) is heavy-weight (less so with Cell widgets though). As a result, you don't want to make them disposable, i.e. throw them away every now and then. You'll rather want to keep one view instance around that you reuse for the lifetime of the app.
Not exactly the same notion of "disposability".
Browser embodies the session (?!?!)
GWT is built of single-page apps. You can store state on the client simply in variables in your app; you don't need cookies or whatever to have the state shared between pages.
Server is stateless - except for caching (?!?!)
Storing session state on the server has a cost (state must be persisted –particularly if the server is disposable–, shared between servers –when you have a cluster / run in the cloud–, etc. you'll spend as many resources keeping existence of your session state as doing actual business logic).
Client never notices a restart (?!?!)
HTTP is a a disconnected protocol. If the server is restarted, the client won't know about it, and it shouldn't have to know about it.
If someone could help give me concrete understanding of these 3 items and how they relate to each other I think I'll start to "get gwt".
It's not about getting GWT, it's about getting the Web and getting single-page webapps, and how to scale them.
Whether they're made with GWT or jQuery on the client-side, and Java or Python or .NET on the server-side doesn't matter.
Read about REST, it sums it all.
In Java web application, Java servlet create unique jsessionid that passes as cookie to the client browser to keep track of the client's subsequent requests after the first one. But when cookies disabled and URL rewriting is not allowed due to security policy, my understanding is that Java servlet would create a new session object for every request from the same client. Is this correct? And does it mean a lot of wastage of server memory ( excessive memory allocation for each session object that is never going to be used again and excessive garbage collection)?
One solution is to use in such scenario is to use client's IP address and user agent string to uniquely identify the user and store in database. Is this correct solution?
Above scenario is fairly common in case of search engine bots which typically makes thousands of frequent requests when they visit the site.
Any other thoughts on crafting proper solution for this problem for a Java based web application?
Yes, in that situation sessions will be created every time. These do cost memory and will need to be GC'ed eventually.
If you don't need to track users you can always opt to disable the creation of sessions. In JSP this is a bit difficult, since a page normally always creates a session. There is a directive to turn this off though.
You can however write a filter and servlet request wrapper that prevents sessions from being created.
In JSF there is a very unfortunate bug in the much used Mojorra 2.04 implementation that makes it more or less impossible to do this, but luckily Mojarra 2.1.0 has fixed this.
In case that you really do need to track users, a form of fingerprinting could be used. This is always approximate though and I don't think you should ever use this for a login. IP + user agent is a form of fingerprinting, but because of proxies and large organizations installing the exact same browser for all their workstations this is quite unreliable. It's okay for usage statistics, but totally unsuited for logins.
Alternatives are using HTTPS/SSL, as this protocol has a build-in kind of "session ID", or using DOM or Flash storage, which not everyone who disables cookies also disables.