[Zope3-dev] Re: zope.app.rdb bug?
Jeff Rush wrote: Dmitry Vasiliev wrote: David Johnson wrote: I am using the zope database adapter, and on occasion (1/20) the following code intermittently throws an exception (1/20 times), even though the connection is connected. It's a known bug, see http://www.zope.org/Collectors/Zope3-dev/582. The problem is that the adapter sometimes can't be loaded from the ghost state. However, I still can't understand why the connection is closed (or reported as closed) while the request should be still in process... If it's related to persistence, then perhaps a workaround for David in the meantime would be to supply the connector as a global utility not stored in the ZODB. I haven't seen the problem occur here and perhaps that's because I declared my adapter in site.zcml so it never gets ghosted: I guess the adapter should work just fine as global utility, but we need to fix the bug anyway. -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: zope.app.rdb bug?
David Johnson wrote:
In regards to persistence, are we saying this problem occurs when the
connection is an attribute of a persistent object? In our case the
connection resides in a persistent object but is called and used in a
non-persistent one.
It doesn't matter if the 'caller' of the connection is persistent or not, but
that the connector is itself a persistent, local utility stored in the site
manager folder.
Specifically, we're using the connection in a
non-persistent shopping cart object. Upon initialization the cart object
retrieves the connection from a persistent parent in the context in which
the cart is initialized. In this way, different shopping cart items can be
stored in different databases depending upon the container. The parent is
essentially a copy of ISQLScript.
I copied SQLScript as well. Be sure that on each SQL operation you re-fetch
the connection object using the connection name. Do not hold on to the
connection object itself, as it may change during system re-configuration.
Here is my calling method:
def invoke_SQL(self, query):
cache = getCacheForObject(self)
location = getLocationForCache(self)
if cache and location:
_marker = object()
result = cache.query(location, {'query': query}, default=_marker)
if result is not _marker:
return result
try:
connection = zapi.getUtility(IZopeDatabaseAdapter,
self.connection_name)()
except KeyError:
raise AttributeError, (
The database connection '%s' cannot be found. % (
self.connection_name))
result = queryForResults(connection, query)
if cache and location:
cache.set(result, location, {'query': query})
return result
Notice the zapi.getUtility() call to re-fetch each time.
-Jeff
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] RE: zope.app.rdb bug?
Good. I think I'm clear. That procedure is exactly what I am following,
except I don't cache queries for this application. My database connection
is a persistent utility. I'll give the global utility a try.
-Original Message-
From: Jeff Rush [mailto:[EMAIL PROTECTED]
Sent: Monday, April 17, 2006 9:27 AM
To: David Johnson
Cc: zope3-dev@zope.org
Subject: Re: zope.app.rdb bug?
David Johnson wrote:
In regards to persistence, are we saying this problem occurs when the
connection is an attribute of a persistent object? In our case the
connection resides in a persistent object but is called and used in a
non-persistent one.
It doesn't matter if the 'caller' of the connection is persistent or not,
but
that the connector is itself a persistent, local utility stored in the
site
manager folder.
Specifically, we're using the connection in a
non-persistent shopping cart object. Upon initialization the cart
object
retrieves the connection from a persistent parent in the context in
which
the cart is initialized. In this way, different shopping cart items can
be
stored in different databases depending upon the container. The parent
is
essentially a copy of ISQLScript.
I copied SQLScript as well. Be sure that on each SQL operation you re-
fetch
the connection object using the connection name. Do not hold on to the
connection object itself, as it may change during system re-configuration.
Here is my calling method:
def invoke_SQL(self, query):
cache = getCacheForObject(self)
location = getLocationForCache(self)
if cache and location:
_marker = object()
result = cache.query(location, {'query': query},
default=_marker)
if result is not _marker:
return result
try:
connection = zapi.getUtility(IZopeDatabaseAdapter,
self.connection_name)()
except KeyError:
raise AttributeError, (
The database connection '%s' cannot be found. % (
self.connection_name))
result = queryForResults(connection, query)
if cache and location:
cache.set(result, location, {'query': query})
return result
Notice the zapi.getUtility() call to re-fetch each time.
-Jeff
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope.app.rdb bug?
On Mon, Apr 17, 2006 at 09:27:07AM -0500, Jeff Rush wrote:
Specifically, we're using the connection in a
non-persistent shopping cart object. Upon initialization the cart object
retrieves the connection from a persistent parent in the context in which
the cart is initialized. In this way, different shopping cart items can be
stored in different databases depending upon the container. The parent is
essentially a copy of ISQLScript.
I copied SQLScript as well. Be sure that on each SQL operation you re-fetch
the connection object using the connection name. Do not hold on to the
connection object itself, as it may change during system re-configuration.
Here is my calling method:
def invoke_SQL(self, query):
cache = getCacheForObject(self)
location = getLocationForCache(self)
if cache and location:
_marker = object()
result = cache.query(location, {'query': query}, default=_marker)
if result is not _marker:
return result
try:
connection = zapi.getUtility(IZopeDatabaseAdapter,
self.connection_name)()
except KeyError:
raise AttributeError, (
The database connection '%s' cannot be found. % (
self.connection_name))
result = queryForResults(connection, query)
if cache and location:
cache.set(result, location, {'query': query})
return result
Notice the zapi.getUtility() call to re-fetch each time.
At one point in sqlos development we were re-fetching the connection
every time to get local utilities working. That turned out to have a
noticeable performance penalty, i.e. people noticed and started to
complain;)
So these days we have a per thread cache that is cleaned out before
traversing a site and at the end of every request.
--
Brian Sutherland
Metropolis - it's the first movie with a robot. And she's a woman.
And she's EVIL!!
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: zope.app.rdb bug?
Dmitry Vasiliev wrote: David Johnson wrote: I am using the zope database adapter, and on occasion (1/20) the following code intermittently throws an exception (1/20 times), even though the connection is connected. It's a known bug, see http://www.zope.org/Collectors/Zope3-dev/582. The problem is that the adapter sometimes can't be loaded from the ghost state. However, I still can't understand why the connection is closed (or reported as closed) while the request should be still in process... If it's related to persistence, then perhaps a workaround for David in the meantime would be to supply the connector as a global utility not stored in the ZODB. I haven't seen the problem occur here and perhaps that's because I declared my adapter in site.zcml so it never gets ghosted: rdb:provideConnection name=dbfinance component=psycopgda.adapter.PsycopgAdapter dsn=dbi://webaccountant:[EMAIL PROTECTED]/finance / -Jeff ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
