Bah. You don't really need to store the pages. You only need to store how they can be reconstructed...
Cheers, Anjo Am 08.03.2010 um 18:07 schrieb Mike Schrag: > Even within Apple, I would suspect that worked under VERY specific > restrictions about what can be in your session at any point in time ... As > soon as you start persisting the backtrack cache, it's going to get crazy > complicated. > > On Mar 8, 2010, at 11:40 AM, Pascal Robert wrote: > >> So nobody outside Apple have been able to do this? :-( >> >>> when you're done implementing persistent session, let me know ... >>> >>> ms >>> >>> On Mar 8, 2010, at 11:13 AM, Johan Henselmans wrote: >>> >>>> I store a persistent PDsession EO (not related to WOSession): if a user is >>>> timed out in a WOSessions, the next time the user logs in, the information >>>> from the PDsession is restored unless they explicitely close it. >>>> >>>> The problem that occurs is that sometimes a user logs itself in twice, so >>>> the information in the PDsession is updated from two browsers. >>>> >>>> So I have to prevent a user to log in twice. >>>> >>>> An option I thought of was: >>>> -store a WOSessionID in thePDsession >>>> -when the user logs in, check if that session is still available in the >>>> applications WOSessionStore. >>>> -if so, refuse login >>>> >>>> Problem is that (as far as I know) applications do not share the >>>> sessionID's so if there would be another WOApplicatiion that has the same >>>> requirement, the user would still be able to login. >>>> >>>> So I thought of changing the WOSessionStore to something persistent, >>>> instead of residing it in memory, and let the applications that have to >>>> make use of such a requirement (user can only login on specific >>>> application) to store their sessions in a persistent place. >>>> >>>> In noticed that way is also mentioned in: >>>> >>>> http://developer.apple.com/legacy/mac/library/documentation/MacOSXServer/Reference/WO54_Reference/com/webobjects/appserver/WOSessionStore.html >>>> >>>> " >>>> There is one subclass of WOSessionStore implemented for the developer's >>>> convenience. A server WOSessionStore (the default) stores session state in >>>> the server, in application memory. The serverSessionStore method returns >>>> this WOSessionStore. >>>> >>>> You can create a custom session store by making a subclass of >>>> WOSessionStore. The subclass should properly implement the >>>> saveSessionForContext andrestoreSessionWithID methods and should have a >>>> public method that the application object can use to obtain an instance. >>>> Some interesting session stores could be: >>>> >>>> • A database session store that stores session data in a database as >>>> blobs, with the session ID as the primary key. This kind of WOSessionStore >>>> can be shared by many instances of the same WebObjects application, thus >>>> distributing the load (requests) among the instances. >>>> • An adaptive session store that stores session state either in cookies >>>> or on the server, depending on what the client supports. >>>> If you create your own WOSessionStore class that generates persistent >>>> objects, you should implement an algorithm that cleans up session state >>>> after the session is inactive for a long time. The server WOSessionStore >>>> provided by WebObjects performs this clean-up properly, but the API is not >>>> yet public. >>>> " >>>> >>>> I also noticed that in the Developer Examples There is the >>>> WOSessionStoreExample Framework, that seems to implement something like >>>> this. >>>> >>>> Does anybody have any experience with this technique, does it solve the >>>> problem I am trying to tackle or is there another approach more >>>> appropriate? >>>> >>>> >>>> >>>> Johan Henselmans >>>> jo...@netsense.nl >>>> >>>> >>>> >>>> _______________________________________________ >>>> Do not post admin requests to the list. They will be ignored. >>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>>> Help/Unsubscribe/Update your Subscription: >>>> http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40mdimension.com >>>> >>>> This email sent to msch...@mdimension.com >>> >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>> Help/Unsubscribe/Update your Subscription: >>> http://lists.apple.com/mailman/options/webobjects-dev/probert%40macti.ca >>> >>> This email sent to prob...@macti.ca >> > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/anjo%40krank.net > > This email sent to a...@krank.net _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
