Valentino Volonghi aka Dialtone ha scritto:
On Tue, 01 Aug 2006 19:10:23 +0200, Manlio Perillo firstname.lastname@example.org wrote:
Not really unless you want your system on its knees begging for some holidays. Just think about the chance for 1M people to visit your website each day. Your sessions database will shortly be the biggest bottleneck of the application.
But then why store sessions in a database at all?
Beucase registered users that are logged in and required to be remembered are asking for that.
Ok, but you can store the session in a global dictionary (as done in your default implementation). The sessions are available, at least if the server is not rebooted.
I think that a database should be used only if you want to share sessions beetwen distributed servers (or if you are using a server like Apache).
By the way: what's the difference beetwen ctx.remember/locate and storing attributes on the context/request?
Too long and complicated to explain and not worth it. but storing data on the request is always a bad idea. And storing data on the session is mostly a bad idea. Storing data in the database is not a bad idea.
No, I meant storing data that shoud be stored for the "lifetime of the rendering".
As done in formal with the forms data and errors. Where should be this data stored?
The request object is not good?
Sorry, I did not noticed that it was a callback! Only a question: sessionwrapper is self.guard?
what is self?
def loggedIn(self, session, request, sessionwrapper):
anyway I guess yes, searching for the place where loggedIn is called is a much easier way to find the answer.
So sessionwrapper parameter is not needed?
I think that serverside state is not needed here, cookies come for this.
Cookies come to identify all the requests coming from the same browser, they are not meant to store server side state, although they can keep 32k of data.
Sometimes one only needs to know the authenticated username (to personalize some portions of a page).
This is something that is already available to authenticated users. I think you mean un-authenticated users here.
Yes, but guard requires a lot of "things" to happen for every request.
I would like to do some benchmark, but if I only need to know the authenticated username, maybe I have no need for a session wrapper (but I need the session manager).
Thanks and regards Manlio Perillo