Temporary Folder Content - Session Data
Sometimes I feel really bad writing to the list for help. It's when I have very simple, very basic questions. I'm sure that the answer is somewhere, but I've not been able to find it. I'm having a thought that each of my Zope projects that uses sessions should use individual session containers. I had some problems when one of our student developers and I both shared the same variable names. Quite hilarious. However, it seems to be conventional wisdom to store session data containers in temporary folders, as the default session data container is. This of course goes away on a restart. Is there anyway to get them to stick, as the default session data container does? Thanks a ton Edward
On Tue, 2003-05-27 at 11:53, Edward Pollard wrote:
Sometimes I feel really bad writing to the list for help. It's when I have very simple, very basic questions. I'm sure that the answer is somewhere, but I've not been able to find it.
The likeliest place to find information about sessions in in the 2.6 edition of the Zope Book at http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition/Sessions.stx
I'm having a thought that each of my Zope projects that uses sessions should use individual session containers. I had some problems when one of our student developers and I both shared the same variable names. Quite hilarious.
Session data containers contain session data objects, each of which should be unique for a particular browser (user). It's true that each developer will share the same session namespace for a given user, but you don't need to limit yourself to storing string-valued key-value pairs in the top-level namespace of the session data object. For example, instead of: context.REQUEST.SESSION['avariable'] = 'avalue' ... you can do something like this: my_app_namespace = context.REQUEST.SESSION.get('my_app', {}) my_app_namespace['avaraible'] = 'avalue' context.REQUEST.SESSION.set('my_app', my_app_namespace) In this case you are storing a dictionary named 'my_app' in the session which (as long as no other developer uses 'my_app' as a top-level session key) can be private to your application. Read the section entitled "Mutable Data Stored Within Session Objects" in the Zope Book sessions chapter to understand the 3rd line of the above example.
However, it seems to be conventional wisdom to store session data containers in temporary folders, as the default session data container is. This of course goes away on a restart.
Is there anyway to get them to stick, as the default session data container does?
I'm afraid I don't understand what this has to do with namespace conflicts... but you can create a session data container in your "main" ZODB by selecting it from the Add... menu. Then point your session data manager at it. The data will not go away then but it will be much more prone to conflicts and thus perhaps performance problems. This is also detailed in the Zope Book chapter. - C
Session data containers contain session data objects, each of which should be unique for a particular browser (user). It's true that each developer will share the same session namespace for a given user, but you don't need to limit yourself to storing string-valued key-value pairs in the top-level namespace of the session data object. For example, instead of:
context.REQUEST.SESSION['avariable'] = 'avalue'
... you can do something like this:
my_app_namespace = context.REQUEST.SESSION.get('my_app', {}) my_app_namespace['avaraible'] = 'avalue' context.REQUEST.SESSION.set('my_app', my_app_namespace)
Is this the only way to have separate session objects in an application? I tried to place two Session Data Managers in one folder. I tolds the first of them to Place SESSION in REQUEST object as "ses1", and the second one to place it as "ses2". Zope seems to use only the first one. When I listed the REQUEST, it contained "ses1" and "SESSION" (inherited from default Session Data Managers). That made me think that I can at least place a new Session Data Managers hierarchic subfolders and all of them will be visible. A drawing will easier to understand: folderA/ SDM1 (place session as "ses1") folderB/ SDM2 (place session as "ses2") folderC/ SDM3 (place session as "ses3") Surprisingly, when I print REQUEST from folderC, there are only two session objects visible: SESSION and ses3. Why is this? -- Milos Prudek _________________ Most websites are confused chintzy gaudy conflicting tacky unpleasant... unusable. Learn how usable YOUR website is! http://www.spoxdesign.com
On Fri, 2003-09-26 at 12:42, Milos Prudek wrote:
Session data containers contain session data objects, each of which should be unique for a particular browser (user). It's true that each developer will share the same session namespace for a given user, but you don't need to limit yourself to storing string-valued key-value pairs in the top-level namespace of the session data object. For example, instead of:
context.REQUEST.SESSION['avariable'] = 'avalue'
... you can do something like this:
my_app_namespace = context.REQUEST.SESSION.get('my_app', {}) my_app_namespace['avaraible'] = 'avalue' context.REQUEST.SESSION.set('my_app', my_app_namespace)
Is this the only way to have separate session objects in an application?
The result of this isn't two separate session objects. 'my_app' is just a namespace. There can be any number of namespaces in the same session data object. It's the 'recommended way', FWIW.
I tried to place two Session Data Managers in one folder. I tolds the first of them to Place SESSION in REQUEST object as "ses1", and the second one to place it as "ses2". Zope seems to use only the first one. When I listed the REQUEST, it contained "ses1" and "SESSION" (inherited from default Session Data Managers).
Having two session data managers in the same folder isn't really supported.
That made me think that I can at least place a new Session Data Managers hierarchic subfolders and all of them will be visible. A drawing will easier to understand:
folderA/ SDM1 (place session as "ses1") folderB/ SDM2 (place session as "ses2") folderC/ SDM3 (place session as "ses3")
Surprisingly, when I print REQUEST from folderC, there are only two session objects visible: SESSION and ses3.
Why is this?
That's not what I see (Zope 2.7 head). When I print the request, I get SESSION, ses1, ses2, and ses3. This should indeed work (although I'm not sure you'd really want to do this, namespaces seem easier and clearer). - C -- Chris McDonough <chrism@zope.com> Zope Corporation
The result of this isn't two separate session objects. 'my_app' is just a namespace. There can be any number of namespaces in the same session data object. It's the 'recommended way', FWIW.
Separate namespaces is good enough for me.
Having two session data managers in the same folder isn't really supported.
Maybe then it should not be possible to instantiate more than one.
That's not what I see (Zope 2.7 head). When I print the request, I get
I still use Zope 2.5.1, will upgrade soon.
SESSION, ses1, ses2, and ses3. This should indeed work (although I'm not sure you'd really want to do this, namespaces seem easier and clearer).
Perfect. Thank you very much for your explanation. -- Milos Prudek
Edward Pollard wrote at 2003-5-27 09:53 -0600:
Sometimes I feel really bad writing to the list for help. It's when I have very simple, very basic questions. I'm sure that the answer is somewhere, but I've not been able to find it.
I'm having a thought that each of my Zope projects that uses sessions should use individual session containers. I had some problems when one of our student developers and I both shared the same variable names. Quite hilarious.
There is a way to do this without separate containers: Use namespaces, identified via prefixes. Eg.: User.Name, User.Number, User.Id (--> namespace "User") Student.Name, Student.Number (--> namespace "Student") You would use different session containers only when they need different parameterization (e.g. different timeouts) or different features (e.g. one managed via ZEO, one managed in RAM). When you think you really need different containers: The standard "session container" is created during Zope startup in "OFS/Application.py" (search for "temp_folder"). You could change the code there. There is a product "InitScripts" (I think) that allows you to configure Zope startup via scripts. You might use it to add additional session containers on startup. Dieter
However, it seems to be conventional wisdom to store session data containers in temporary folders, as the default session data container is. This of course goes away on a restart.
I have encountered the same problem. Probably my solution will help you: We use separate session data object for each project. In my project all files are located under /projects/prj123/. Here's a recipe: 1. Create Temporary Folder with id 'temp_folder' under /projects/prj123/ 2. Create Session Data Manager under /projects/prj123/ 2.1 Set Session Data Manager property "Transient Object Container Path" to "temp_folder/sesion_data" 3. Make sure that the following snippet is executed before any code manipulating session data: tf = context.temp_folder if not hasattr ( tf, 'session_data' ): tf.manage_addProduct[ 'Transience' ].constructTransientObjectContainer ( 'session_data', 'Session Data Object' ) (The code may reside in a login script or you may use __before_traverse__ mechanism) Regards, Dmitry
participants (5)
-
Chris McDonough -
Dieter Maurer -
Dmitry Dembinsky -
Edward Pollard -
Milos Prudek