Re: [Zope] storing persisten object in python dictionaries
On 10/26/06, Jürgen Herrmann <Juergen.Herrmann@xlhost.de> wrote:
On Thu, October 26, 2006 14:53, Marco Bizzarri wrote:
Storing persistent object in object outside of ZODB can incur in the problem of passing object(s) between threads, and, therefore, passing one object which is related to a connection on the ZODB to another context with a different connection.
ok, this is probably the problem here, so would haveing a cache dict for each thread help? there are only about 50-100 containers so the memory overhead would be neglible compared to the performance gained.
Yes, this should probably resolve your issue.
Also, AFAIK, keep in mind _v_ attributes are not involved in transaction machinery of Zope. This means that if you have an error inside you transaction after you modified the _v_ cache, you will have the cache modified even tough the transaction has been aborted.
not a real problem as class instance containers are very static.
I understand, we hit this problem while caching object obtained from database rows... and in case of failure cache became unreliable. I'm keeping the answer on the ML, if you don't mid. -- Marco Bizzarri http://iliveinpisa.blogspot.com/
On Thu, October 26, 2006 15:00, Marco Bizzarri wrote:
On 10/26/06, Jürgen Herrmann <Juergen.Herrmann@xlhost.de> wrote:
On Thu, October 26, 2006 14:53, Marco Bizzarri wrote:
Storing persistent object in object outside of ZODB can incur in the problem of passing object(s) between threads, and, therefore, passing one object which is related to a connection on the ZODB to another context with a different connection.
ok, this is probably the problem here, so would haveing a cache dict for each thread help? there are only about 50-100 containers so the memory overhead would be neglible compared to the performance gained.
Yes, this should probably resolve your issue.
Also, AFAIK, keep in mind _v_ attributes are not involved in transaction machinery of Zope. This means that if you have an error inside you transaction after you modified the _v_ cache, you will have the cache modified even tough the transaction has been aborted.
not a real problem as class instance containers are very static.
I understand, we hit this problem while caching object obtained from database rows... and in case of failure cache became unreliable.
I'm keeping the answer on the ML, if you don't mid.
of course, my failure while responding.
-- Marco Bizzarri http://iliveinpisa.blogspot.com/ _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
_______________________________________________________________________
XLhost.de - eXperts in Linux hosting <<
Jürgen Herrmann Konrad Adenauer Allee 43, DE-93051 Regensburg Fon: +49 (0)700 XLHOSTDE [0700 95467833] Fax: +49 (0)721 151 463027 WEB: http://www.XLhost.de
On Thu, October 26, 2006 15:00, Marco Bizzarri wrote:
On 10/26/06, Jürgen Herrmann <Juergen.Herrmann@xlhost.de> wrote:
On Thu, October 26, 2006 14:53, Marco Bizzarri wrote:
Storing persistent object in object outside of ZODB can incur in the problem of passing object(s) between threads, and, therefore, passing one object which is related to a connection on the ZODB to another context with a different connection.
ok, this is probably the problem here, so would haveing a cache dict for each thread help? there are only about 50-100 containers so the memory overhead would be neglible compared to the performance gained.
Yes, this should probably resolve your issue.
ok, just reimplemented my _classContainer(className) method as follows: def _classContainer(self, className): """ return the instances folder for className """ thread = currentThread() containerDict = getattr(thread, '_relClsContainerDict', None) if containerDict is None: containerDict = {} thread._relClsContainerDict = containerDict container = containerDict.get(className, None) if container is None: container = self.unrestrictedTraverse(self._classContainerPath(className)) containerDict[className] = container return container it seems to work fine, all tests pass, though i have a somewhat bad feeliong of setting an attribute on the thread object directly. comments? best regards, jürgen herrmann _______________________________________________________________________
XLhost.de - eXperts in Linux hosting <<
Jürgen Herrmann Konrad Adenauer Allee 43, DE-93051 Regensburg Fon: +49 (0)700 XLHOSTDE [0700 95467833] Fax: +49 (0)721 151 463027 WEB: http://www.XLhost.de
participants (2)
-
Jürgen Herrmann -
Marco Bizzarri