I think its a good idea to have them co-exist... but...
> The system must propose to use RAM and File/DB storage. > Both should be usable at the same time (RAM for performance, and FILE/ > DB for large storage) > Of course DB will permit to share session against multiple server > (using loadbalancing) I've encountered an "issue" with CP's RAM-based session mgmt. Jonathan LaCour briefly alludes to it in: http://docs.turbogears.org/1.0/LightTPD way at the bottom, in the "caveats" section... It has to do with RAM-based CP session mgmt not working properly with flup-based lighty (possibly-nginx-and-other-too) proxying. For some reason, session info "persisted" on one thread doesn't seem to become available for some latter formed new threads. Also, by default, CP's session mgmt creates a SessionID (and a cookie) for every request coming in to the TG-app. This can be problematic for cases of low resource (RAM or disk-space) availability. In theory, someone ould bang the system, have numerous sessions get created. The problem is multiplied, when the sesion-mgmt cleanup logic doesn't get triggered (assuming you have not configured right) in a timely fashion, reclaiming the resources used for these bogus sessions. I think you proposal may work if: 1. CP's sessionfilter is rewritten taking the above pts into consideration 2. Folks are disuaded from requiring/using RAM-based sessions in proxy-based usage scenarios, and 3. Session mgmt (cleanup) etc are trigggered in a timely fashion, so resource usage is more resonable. Just some thoughts... /venkat --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" 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/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
