search

SeasideSt / Seaside

The framework for developing sophisticated web applications in Smalltalk.
MIT License
516 stars 71 forks source link

cached configurations on Session #184

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
We discussed at one point having a CachedConfiguration class and putting
one on Session. It would cache the result of any preference lookup, which
would significantly reduce the number of searches through the configuration
hierarchy.

This would obviously mean that all preference lookups would want to go
through the session (which makes logical enough sense) but also that
configuration changes to the application might not take effect in existing
sessions (possibly good or bad depending on your point of view).

Original issue reported on code.google.com by jfitz...@gmail.com on 22 Sep 2008 at 11:13

GoogleCodeExporter commented 9 years ago 
Looks like this was part of Issue 608... Julian?

Original comment by avish...@gmail.com on 26 Feb 2011 at 10:29

GoogleCodeExporter commented 9 years ago 
I don't think so Issue 608 caches "just" the search contexts. This would cache 
the actual values in the session.

Original comment by philippe...@gmail.com on 27 Feb 2011 at 10:55

GoogleCodeExporter commented 9 years ago 
There's an open question here - is it good or bad to have configuration changes 
in the application not to take effect in existing sessions?

There are obviously cases for each argument, but I believe that we shouldn't 
create situations which will "surprise" developers, such as inconsistent 
session configuration.

Original comment by avish...@gmail.com on 27 Feb 2011 at 12:59

GoogleCodeExporter commented 9 years ago 
Of course. But you can define "inconsistent" session configuration as either:
  "containing different attributes than other sessions"; or
  "containing different attributes/values than when the session was created"

Personally, I think I still lean towards thinking the caching would be a good 
idea, but I'm not sure and I haven't thought about the implications recently.

(thanks for asking these questions, by the way, Avi)

Original comment by jfitz...@gmail.com on 28 Feb 2011 at 2:10

GoogleCodeExporter commented 9 years ago 
No problem, discussion is important :)

Either cases you have described ("inconsistent" session configuration) will 
surprise other developers when they encounter it. I feel like we will be 
creating a "sessions gap" between configuration updates, which will puzzle 
developers as to why their users' sessions are not updated.

Here's a scenario:
A developer is attempting to update his image on a live production server. The 
update makes some changes to configurations which will create the effect of 
"inconsistent" session configuration. As a result, users which already hold a 
session will have inconsistent configuration values.
Now what if the developer is making a big change, one under which the old 
configuration is simply not consistent with the program logic? Wouldn't this 
cause the program to break for the users already holding a session?

I'd hate to see Seaside taking part of the "blame" when someone's application 
starts behaving weird because of this.

Original comment by avish...@gmail.com on 28 Feb 2011 at 6:04

GoogleCodeExporter commented 9 years ago 
Right, exactly. Both will surprise developers and we can't avoid both. By 
caching we avoid the second form but allow the first. By not caching we avoid 
the first but allow the second.

If we cache, not only do we get a speed improvement but it would also be quite 
easy to tell all the sessions to clear their cached configurations if you 
specifically wanted them to pick up the new configuration. I think we could 
probably also drop the caching in Issue 608 and possibly even the caching of 
the configuration descriptions (the caching of which is probably the most 
likely to surprise developers).

The disadvantage of caching via the session, of course, is that non-application 
request handlers wouldn't benefit from it (though I suppose they could at least 
cache per-request in the RequestContext).

Original comment by jfitz...@gmail.com on 1 Mar 2011 at 11:21

GoogleCodeExporter commented 9 years ago 
I don't mind caching configurations in sessions, but this will simply move the 
problem to another place (with different problems as mentioned).

I think both approaches are incomplete because of their underlying 
implementation. WASystemConfiguration>>#describeOn: uses code to describe the 
configurations. Because of this. both approaches run into caching problems. I'm 
not saying that this is wrong, just that these caching issues will always 
pop-up in any place where data is represented as methods.

What do you think about configuration using reactive programming [1], sort of 
an Observer for configurations? We can use it to do the opposite of the current 
implementation - notify the *children* of a parent configuration when the 
configuration has changed.
Using this approach, the configurations will be constructed at #initialize: , 
and will be mutable using instance methods that add/remove configuration 
descriptions.

It might be more adequate than the current configuration-as-code approach.

 [1] http://en.wikipedia.org/wiki/Reactive_programming

Original comment by avish...@gmail.com on 1 Mar 2011 at 6:24

GoogleCodeExporter commented 9 years ago 
I'm not a big fan of class-side initialization - it makes a mess, particularly 
when upgrading since you can never figure out what's been run when and in what 
order. When you through in differences between platforms it gets even worse. 
Also, how do you ensure that changes made with the instance methods are written 
back to version control?

You could make the cached configurations on the sessions observers of the 
application's UserConfiguration. You could then update the caches (either 
automatically or at the request of the admin) when the configuration settings 
are changed.

However, a session is conceptually an instance of an application, and if you 
draw the parallel to desktop applications, most do not re-read their 
configurations from disk after they have launched. Some do, of course, but I'd 
say that's the far less common scenario (thus the -HUP signal on *nix to coax 
them to do so). I'm still not convinced that a similar pattern is a problem 
here.

Original comment by jfitz...@gmail.com on 15 Mar 2011 at 8:44

GoogleCodeExporter commented 9 years ago 
Sessions are not parallel to desktop applications. Whereas desktop applications 
do stand alone after they have been launched, sessions are tied to server code 
that's alive and running on the server on each page render/callback. If the 
code on the server has changed, some users will end up with invalid sessions 
(i.e. sessions with invalid data/consistency with server model).

Caching configurations and descriptions is one thing, and can be managed 
locally (as currently implemented). Caching sessions is unexpected, and brings 
troubles to the user domain. Again, I'd hate to see Seaside taking any "blame" 
for dangling sessions.

Original comment by avish...@gmail.com on 16 Mar 2011 at 12:55

GoogleCodeExporter commented 9 years ago 
We're going in circles. As I already said, it is potentially *just* as 
surprising and problematic for sessions to take on new settings after they have 
been created. They may have needed to be initialized a certain way based on the 
settings.

You're talking about the case of code changing while the application is 
running. If you are doing that, you'd better be stopping requests momentarily 
at least while you load the code - otherwise you'll have requests being 
processed while half of the new code is loading and that is guaranteed to blow 
up in your face. You better also be updating all the cached continuations and 
component state, since those might have changed as well. Updating code is an 
ugly, ugly problem as it is - refreshing cached configuration state - if that 
is what you desire - is the least of your worries, and at least you would have 
the choice one way or the other.

Original comment by jfitz...@gmail.com on 16 Mar 2011 at 9:16