--- On Wed, 8/20/08, Andrew Milton <akm@theinternet.com.au> wrote:

From: Andrew Milton <akm@theinternet.com.au> Subject: Re: [Zope] Need some help to get rid of an InvalidObjectReference exception To: "chaouche yacine" <yacinechaouche@yahoo.com> Cc: zope@zope.org Date: Wednesday, August 20, 2008, 5:27 AM +-------[ chaouche yacine ]---------------------- | | Ok here's how I did to finally fix it : | | * create a new Transient Object Container (sessionTOC) at root | * create a new Session Data Manager (sessionDM), with the following settings : | ** Id : sessionDM | ** Transient Object Container Path : /sessionTOC | ** Place SESSION in REQUEST object as : ZODBSESSION | | Now I can put ZODB objects in ZODBSESSION using something like : | | context.REQUEST.ZODBSESSION.set("object",o) | | Thanks to all of you for your precious help.

Your main ZODB will grow everytime you add or remove something in ZODBSESSION, you're essentially storing the same object twice in your ZODB.

-- Andrew Milton akm@theinternet.com.au

Correct. I Quit... :( better not to store ZODB objects in the session and try to get some way around.

+-------[ chaouche yacine ]---------------------- | | Correct. I Quit... :( better not to store ZODB objects in the session and try to get some way around.

So now you can go look at the Cache objects that Zope provides :-)

-- Andrew Milton akm@theinternet.com.au

If you are talking about RAM cache, HTTP cache etc., I don't know if they'll do the trick because, again, it's about caching objects that do not live in the ZODB, i.e I cannot go in the ZMI and click the cache tab on a python script or a page template because that's not what I am trying to do. But maybe there's the volatile attributes alternative, and that fails too then I have no choice but to do the caching mechanism myself...

Whatever you are doing, you are doing the "wrong thing".

You are instantiating persistent objects and not storing them in the ZODB. This is going to cause your ZODB to grow, so you might as well store them.

Otherwise you need to make non-persistent versions of the objects you are trying to 'cache' and use those instead.

-- Andrew Milton akm@theinternet.com.au

Not exactly. I am instantiating non persistent objects that do have a reference to persistence objects in the form of an attribute, and then trying to cache those non persistent objects. Do the fact that these non persistent objects store a reference to persistent ones turn them into persistent ? I am curious to know. Anyway, I tried the volatile attribute thing (http://wiki.zope.org/ZODB/VolatileAttributes) and first tests look fine. This is how I did the trick : =================== ZODBLivinObject.py =================== from OFS.SimpleItem import SimpleItem from NonZODBObject import NonZODBObject class ZODBLivingObject(SimpleItem) : """ Hello, I live in the ZODB. """ meta_type = "ZODBish" def __init__(self): """ """ self.id = "ZODBish" self.title = "ZODBish" def sayHi(self): """ """ # NonZODBObject stores a reference of self, a ZODB-living object. nonZODBish = NonZODBObject(self) # This line breaks everything. Comment it and every thing will be just right. # self.REQUEST.SESSION.set('breakish',nonZODBish) self.setNonZODBish(nonZODBish) # This can be seen in the console if runzope print "it's me",nonZODBish.context return nonZODBish.context def setNonZODBish(self,p_nonZODBish): """ """ setattr(self,'_v_NonZODBish',p_nonZODBish) def getNonZODBish(self): """ """ if not hasattr(self,"_v_NonZODBish"): self.setNonZODBish(None) return self._v_NonZODBish And then I use the setNonZODBish et getNonZODBish methods to set and access the cached value.

You understand that _v_ attributes are only available in the thread they were created, and will disappear when the object leaves the object cache.

If you manage to get a 2nd thread there will be nothing in the _v_ attribute, or wait 10 or so mins between requests...

-- Andrew Milton akm@theinternet.com.au

Yes this could be dangerous, but in my case these volatile attributes need not to be in the cache for a very long time, it's just a matter of 3 or 4 clicks in about half a dozen of minutes. But yeah, I'll really have to be careful about that, or to recreate them if they're gone (hence the setattr and getattr to make sure there's something in self._v_something and create one if there's not)