2.5 upgrade, Sessions - too clever for myself
Rather than doing the 2.5 Session upgrade work-around, I thought I'd be smart and delete the session_data_manager before restarting Zope (after changing start to use zope-2.5 pythonhome rather than Zope-2.5b3) No I keep getting AttributeError on request.SESSION.getSessionData() Seems the SESSION object doesn't have this method anymore. However if I create a new session_data_manager lower in the tree, and point that at a new transient object container in /temp_folder, then it works again. However if I restart zope, the transient object I created disappears. Seems to be a problem in /temp_folder/session_data, except that even if I create a new transient object /temp_folder/mysession and point the root session_data_manager object at it, I still get attributeError on getSessionData(0 Anyone have any ideas? Or do I need to go to a backup? Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com AOL-IM: BKClements
Brad Clements wrote:
Rather than doing the 2.5 Session upgrade work-around, I thought I'd be smart and delete the session_data_manager before restarting Zope (after changing start to use zope-2.5 pythonhome rather than Zope-2.5b3)
No I keep getting AttributeError on request.SESSION.getSessionData()
Seems the SESSION object doesn't have this method anymore.
However if I create a new session_data_manager lower in the tree, and point that at a new transient object container in /temp_folder, then it works again.
However if I restart zope, the transient object I created disappears.
Seems to be a problem in /temp_folder/session_data, except that even if I create a new transient object /temp_folder/mysession and point the root session_data_manager object at it, I still get attributeError on getSessionData(0
Anyone have any ideas? Or do I need to go to a backup?
I think this is coming from the before traversal hook of the session data manager. What you can do is create a session_data_manager in the old spot (the root) and then change its SESSION attribute name from the management screens to blank (null) -- that will get rid of the traversal hook -- then you can delete it and replace it with a dummy object again. -- Matt Kromer Zope Corporation http://www.zope.com/
On 12 Feb 2002 at 14:37, Matthew T. Kromer wrote:
I think this is coming from the before traversal hook of the session data manager. What you can do is create a session_data_manager in the old spot (the root) and then change its SESSION attribute name from the management screens to blank (null) -- that will get rid of the traversal hook -- then you can delete it and replace it with a dummy object again.
Well, it seems worse actually. 1. I restored last nights backed up Data.fs and friends 2. I started Zope and got the expected traceback/crash in SessionDataManager 3. I changed the SessionDataManager.py code as directed in the ugprade workaround 4. I started Zope 5. Deleted /session_data_manager 6. Created a DTML method as session_data_manager placeholder 7. changed SessionDataManager.py code back to original 8. Restarted Zope (used restart button, not shutdown and start &) 9. Now, code that used REQUEST.SESSION.getSessionData() fails 10. I deleted the dummy session_data_manager dtml method 11. Restart Zope 12. Now REQUEST.SESSION.getSessionData() works (session_data_manager has re-appeared in /) 13. restart zope 14. Now REQUEST.SESSION.getSessionData() gives AttributeError, because the SESSION object doesn't have that method. 15. Delete session_data_manager object 16. Restart Zope 17. Continue at step 12. So .. session_data_manager object works only when it's first re-added by whatever adds it. On the next restart, it does not work. I need to fix this in the next hour (you know, one of those development semi-production websites :-( Do I move back to 2.5.B3? Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com AOL-IM: BKClements
Brad Clements wrote:
Well, it seems worse actually.
1. I restored last nights backed up Data.fs and friends
2. I started Zope and got the expected traceback/crash in SessionDataManager
3. I changed the SessionDataManager.py code as directed in the ugprade workaround
4. I started Zope
5. Deleted /session_data_manager
6. Created a DTML method as session_data_manager placeholder
I don't understand why you did step 6. It seems extraneous to me.
7. changed SessionDataManager.py code back to original
8. Restarted Zope (used restart button, not shutdown and start &)
Well, I always recommend a shutdown and start... it shouldn't have mattered, though.
9. Now, code that used REQUEST.SESSION.getSessionData() fails
10. I deleted the dummy session_data_manager dtml method
Well, although this undoes step 6, I wouldn't have done it quite that way.
11. Restart Zope
12. Now REQUEST.SESSION.getSessionData() works (session_data_manager has re-appeared in /)
13. restart zope
14. Now REQUEST.SESSION.getSessionData() gives AttributeError, because the SESSION object doesn't have that method.
15. Delete session_data_manager object
What is the session_data_manager object that's reappearing? I trust it is the right one?
16. Restart Zope
17. Continue at step 12.
So .. session_data_manager object works only when it's first re-added by whatever adds it. On the next restart, it does not work.
I need to fix this in the next hour (you know, one of those development semi-production websites :-( Do I move back to 2.5.B3?
-- Matt Kromer Zope Corporation http://www.zope.com/
On 12 Feb 2002 at 15:03, Matthew T. Kromer wrote:
6. Created a DTML method as session_data_manager placeholder
I don't understand why you did step 6. It seems extraneous to me.
An earlier message in this thread suggested this. I'm not sure why. Probably because someone wanted their own session data manager and didn't want one automatically created that injected it's own SESSION into request.
What is the session_data_manager object that's reappearing? I trust it is the right one?
Session Data Manager at /session_data_manager Btw, if I create my own Session Data Manager (named "mysession_data_manager"), I have the same problem. It works just after it's created, but if Zope is restarted it no longer works after restart. Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com AOL-IM: BKClements
One thing to try here is to get into the Zope debugger to delete the offending hook and the session data manager that caused it: $ cd lib/python $ python2.1
import Zope app = Zope.app() del app.__before_publishing_traverse__ app._delObject('session_data_manager') get_transaction().commit()
Brad Clements wrote:
On 12 Feb 2002 at 15:03, Matthew T. Kromer wrote:
6. Created a DTML method as session_data_manager placeholder
I don't understand why you did step 6. It seems extraneous to me.
An earlier message in this thread suggested this. I'm not sure why. Probably because someone wanted their own session data manager and didn't want one automatically created that injected it's own SESSION into request.
What is the session_data_manager object that's reappearing? I trust it is the right one?
Session Data Manager at /session_data_manager Btw, if I create my own Session Data Manager (named "mysession_data_manager"), I have the same problem. It works just after it's created, but if Zope is restarted it no longer works after restart.
Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com AOL-IM: BKClements
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
-- Chris McDonough Zope Corporation http://www.zope.org http://www.zope.com "Killing hundreds of birds with thousands of stones"
On 13 Feb 2002 at 10:01, Chris McDonough wrote:
One thing to try here is to get into the Zope debugger to delete the offending hook and the session data manager that caused it:
I don't think the hook was the problem. The symptons are 1. The REQUEST.SESSION instance has a getSessionData() method only if the server has been restarted without a session_data_manager instance. That is, if the server is working, then I restart it, then REQUEST.SESSION won't have a getSessionData() method. However if I delete /session_data_manager and restart, it then works again. 2. But worse, it seems that after about 20 minutes ( the default timeout for the storage object), the same problem appears. SESSION loses the getSessionData() method once the timeout specified in /temp_folder/session_data has expired. -- My client was really upset, so I couldn't experiment any longer. My solution was to remove the 2.5 provided Session product and install CST 0.9. It's working now. -- Naturally I'd still like to figure this out, how can I help diagnose this? I think it's the transient storage container.. Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com AOL-IM: BKClements
Brad Clements wrote:
I don't think the hook was the problem. The symptons are
1. The REQUEST.SESSION instance has a getSessionData() method only if the server has been restarted without a session_data_manager instance.
That is, if the server is working, then I restart it, then REQUEST.SESSION won't have a getSessionData() method. However if I delete /session_data_manager and restart, it then works again.
I will try to recreate this symptom. I've never seen or heard of anything like it before.
2. But worse, it seems that after about 20 minutes ( the default timeout for the storage object), the same problem appears. SESSION loses the getSessionData() method once the timeout specified in /temp_folder/session_data has expired.
--
My client was really upset, so I couldn't experiment any longer. My solution was to remove the 2.5 provided Session product and install CST 0.9. It's working now.
OK, well that's good to hear.
Naturally I'd still like to figure this out, how can I help diagnose this? I think it's the transient storage container..
Well... I'm not really sure. Let me poke around a bit.p -- Chris McDonough Zope Corporation http://www.zope.org http://www.zope.com "Killing hundreds of birds with thousands of stones"
OK, that was fast. I was able to repeat it. Now... let me ask the five million dollar question. ;-) Since SESSION *is* the session data object, why do you want to be able to call getSessionData() on it reliably? I will work on seeing how the wrapping differs between cases, but this may be a feature and not a bug. - C Brad Clements wrote:
On 13 Feb 2002 at 10:01, Chris McDonough wrote:
One thing to try here is to get into the Zope debugger to delete the offending hook and the session data manager that caused it:
I don't think the hook was the problem. The symptons are
1. The REQUEST.SESSION instance has a getSessionData() method only if the server has been restarted without a session_data_manager instance.
That is, if the server is working, then I restart it, then REQUEST.SESSION won't have a getSessionData() method. However if I delete /session_data_manager and restart, it then works again.
2. But worse, it seems that after about 20 minutes ( the default timeout for the storage object), the same problem appears. SESSION loses the getSessionData() method once the timeout specified in /temp_folder/session_data has expired.
--
My client was really upset, so I couldn't experiment any longer. My solution was to remove the 2.5 provided Session product and install CST 0.9. It's working now.
--
Naturally I'd still like to figure this out, how can I help diagnose this? I think it's the transient storage container..
Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com AOL-IM: BKClements
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
-- Chris McDonough Zope Corporation http://www.zope.org http://www.zope.com "Killing hundreds of birds with thousands of stones"
On 13 Feb 2002 at 10:38, Chris McDonough wrote:
OK, that was fast. I was able to repeat it. Now... let me ask the five million dollar question. ;-) Since SESSION *is* the session data object, why do you want to be able to call getSessionData() on it reliably? I will work on seeing how the wrapping differs between cases, but this may be a feature and not a bug.
I thought request.SESSION was the Session Data Manager, on which I would call getSessionData(create=0)
From session-add.stx
place SESSION in REQUEST as -- If set, the REQUEST variable will be populated with the session object, stored as the given name (default is 'SESSION') I read this as putting the Session Data Manager object into REQUEST as "SESSION", rather than the session data object. Hmm, too many objects that begin with "Session" If you put the session data object into REQUEST, then it will always be created and you can't control it's creation with the session API.. right? -- Looks like I've made a mistake, though its very strange that it ever worked at all. maybe changing the session-add.stx file to say "session DATA object" rather than "session object" would be helpful. Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com AOL-IM: BKClements
Brad Clements wrote:
I thought request.SESSION was the Session Data Manager, on which I would call getSessionData(create=0)
Gotcha.
If you put the session data object into REQUEST, then it will always be created and you can't control it's creation with the session API.. right?
Well, you can still do it the hard way by acquiring a session_data_manager and calling getSessionData on it as is the norm for CST. This still works. It's probably easier to use the REQUEST-based API. If you use the REQUEST-based API, the session isn't actually created until you access the name "SESSION" in the request, at which point a session is either looked up or created. REQUEST.SESSION is populated lazily, in other words. REQUEST.SESSION is always available for use but it's only populated with an actual session data object the first time you use it.
Looks like I've made a mistake, though its very strange that it ever worked at all.
maybe changing the session-add.stx file to say "session DATA object" rather than "session object" would be helpful.
Yes, you're right. -- Chris McDonough Zope Corporation http://www.zope.org http://www.zope.com "Killing hundreds of birds with thousands of stones"
participants (3)
-
Brad Clements -
Chris McDonough -
Matthew T. Kromer