I have always advocated the stateless web, but would like to know what the advocates of the stateful web are saying.
Do you have any situation where stateful is more appropriate than stateless?
+1
A:
Using states generally makes the programmers job easier.
However, states also introduce all sorts of concurrency issues that are simply not present in stateless situations.
This is essentially the debate between functional and imperative programming.
samoz
2009-07-24 12:49:55
I don't really understand what "concurrency issues" you can have in a web application...
musicfreak
2009-12-23 02:31:01
Let's say you have two users on your site at the same time. If they both submit at the same time, would it be possible that they both hit your database or some other service and a race condition ensues?
samoz
2009-12-24 03:07:06
But that's a database issue though; that has nothing to do with whether you are storing state in your web application or not. ACID-compliant databases (i.e. all relational databases) are written to handle these kinds of issues.
musicfreak
2009-12-24 23:35:00
A:
Things like long forms (and really anything that takes more than one page refresh) are much easier with persistent state, since you can actually keep track of what page/stage the user is on in an easy and straight-forward way. However, I personally don't think such a small advantage is worth it, but it greatly depends on the web application in question.
musicfreak
2009-09-23 01:56:02
A:
Our project uses the Wicket web framework, which allows stateful or stateless interaction. Stateful pages have a number of advantages:
- Using a stateful page in wicket makes it easier to perform partial page updates using wicket's AJAX framework
- Stateful is a more "intuitive" programming model. For example, in a wicket page class, I can declare a private member field on the server side, set it when the page is loaded, and access it again every time an AJAX request hits the page to perform some update.
- Wicket prevents most common concurrency problems in the web tier by synchronizing on the user session object when handling a request.
- Storing state on the server side can sometimes improve performance; for example, an object that's time-consuming to construct but has to be available to the page can be loaded only once when the page is first instantiated.
Anything that's possible in a stateful application could also be implemented as stateless - you simply have to store the state on the client, and submit all relevant state information on every request.
Link to wicket: http://wicket.apache.org/
RMorrisey
2009-09-23 02:11:01
A:
I'm in the statefull client-stateless server camp due to scaleability but when facing the hurdles of explaining why this and that became harder to implement using a stateless server, you get kind of resigned in the long run, this is where stateful server shines:). Eventhough I prefer statefull client this is not easy to implement efficiently using asp.net viewstate and perhaps this is where statefull web gets practical. I think statefull client, stateless server makes you more aware of the amount of data that is transported back and forth between tires. That is sometimes hidden until trouble occures using statefull server programming model. Also, going from stateless to statefull is easy (just ignore state info that you are providing since you already know it.. ). Going the opposite is almost impossible/not worth it. Another thing using a statefull server is that clearing state/cache is often a problem when you are using also a statefull client. It's just unintuitive and confusing, or maby just I am :)
Anyhow GWT and many other modern toolkits (Silverlight talking to WCF) seems to prefer stateful client, stateless server due to scaleability issues. Maybe stateful server should be the exception to the stateless rule ... one could choose per page/window.
Jens
2009-10-06 16:51:51