This is more of the idea I had in mind for your architecture: http://zef.me/883/the-share-nothing-architecture
The solution is the shared-nothing architecture, which I first heard of in > an interview with Rasmus Lerdorf . What does this architecture involve? > Simply not sharing anything. No shared data, at least within the webserver. > Sessions are shared, but are shared through the filesystem or database, > which can easily be scaled by using a networked filesystem (NFS, SMB) or by > using a database. DW On Wed, Dec 21, 2011 at 8:57 AM, Dan Wilson <[email protected]> wrote: > Well, one idea I have is to just move the file into a temporary location > you control, and rename it with something that allows you to retrieve it, > and also to remove it after a period of time should it become stale. > > Another idea is to rethink how you are holding your IsLoggedIn logic. If > you had this in a cookie, you wouldn't really have to worry about the > timeout, per se.. > > I almost never use the session for anything but temporary values. That's > because of two reasons: > > > - The session can timeout, as you are experiencing, causing data loss. > - Sessions are nor very well replicated across machines... especially > complex values so if you end up needing a clustered situation and are using > complex values, you will either have a refactor on your hands, or run in to > lots of trouble as people bounce back and forth between machines. > > > > DW > > > > > > DW > > > > > > > On Tue, Dec 20, 2011 at 5:27 PM, jeff <[email protected]> wrote: > >> In my applications authentication event, we check to see if the user >> submitted a form. If they did, we store it in session and then check >> for it later after they login, and then push it back into the form >> scope. >> >> The idea is this: >> >> 1) User just typed in a whole lot of data. >> 2) << in the mean time, user has timed out>> >> 3) User submits form, and instead is confronted with a login screen >> since they timed out (and we've stored there data into session) >> 4) user logs in, and is redirected to the "save action". >> 5) we pull the data out of session, put it back into form, and all is >> well. >> >> This works great until file attachments come into play. Railo stores >> them in webroot/WEB-INF/railo/temp and the file doesn't seem to exist >> after the login. >> >> Is there a best practice way to handle this sort of thing so file >> uploads can be preseved? >> >> -- >> Model-Glue Sites: >> Home Page: http://www.model-glue.com >> Documentation: http://docs.model-glue.com >> Bug Tracker: http://bugs.model-glue.com >> Blog: http://www.model-glue.com/blog >> >> You received this message because you are subscribed to the Google >> Groups "model-glue" group. >> To post to this group, send email to [email protected] >> To unsubscribe from this group, send email to >> [email protected] >> For more options, visit this group at >> http://groups.google.com/group/model-glue?hl=en > > > > > -- > Plutarch - "The mind is not a vessel to be filled but a fire to be > kindled." > -- Plutarch - "The mind is not a vessel to be filled but a fire to be kindled." -- Model-Glue Sites: Home Page: http://www.model-glue.com Documentation: http://docs.model-glue.com Bug Tracker: http://bugs.model-glue.com Blog: http://www.model-glue.com/blog You received this message because you are subscribed to the Google Groups "model-glue" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/model-glue?hl=en
