* David Binger wrote [2005-09-09 09:19:37 -0400]:

> On Sep 8, 2005, at 7:44 PM, Michael Watkins wrote:
> >
> >Any thoughts or suggestions on where to go from here?
>
> Is the ComputedAttribute instance (x) committed to the database?
> (It is, if x._p_oid is not None).
> I'll assume it is.

Yup.

> Is something on the path of references from the root object
> to x invalidated (by a change of attribute in another connection),

In the test scenario described, no, and when I test, its only a single
connection being used. I sprinkled some debug statements in to verify that it
was the same _p_connnection being referenced across the board, and simplified
the server environment (simple_server.py). Again it only appears to happen
via web server/client and not within simple python scripts or from the opendb
CLI.

> or made into a ghost by Connection.shrink()?  If so, the python
> garbage collector may have flushed x, so it starts out fresh
> again when it is reloaded.
> (You could verify this by instrumenting the lines in Connection.shrink
> (),
> where there is a local variable 'removed' that is a set of oids of
> objects
> that have been removed by the garbage collector).
>
> Is Connection.shrink() removing the ComputedAttribute directly?

It appears to be... the ComputedAttribute, semi-randomly it seems, gets added
to the `removed` Set as weakref. Finding or understanding why has eluded me..

> If so, you might get better results by increasing the Connection
> cache size.
> (You could verify this by instrumenting Connection.shrink()
> and looking for the interested object's oid in the 'ghosts' local
> variable.)

I've tried bumping it up from the default (was one of the first stabs I took)
with no joy.

BUT

A little probing of cache size and I've discovered that it was being set at a
default value, which was too low. I should have checked this earlier but was
put off the trail by `opendb` - which, correctly in my mind - reads the
cache_size config item; but `site start scgi appname` starts a scgi process
which is oblivious.

I've not been using scgi all this time; have been using medusa or
simplesever; flipped over to scgi before firing off my original note
yesterday to test cache as an issue, incorrectly believing that scgi on start
up was calling connection.set_cache_size().

Intentional or bug?

Thanks for the hints anyway, was informative digging through Durus a little
deeper...

Mike