[ZODB-Dev] __del__ with Persistent objects

Stuart Bishop zen at shangri-la.dropbear.id.au
Fri Jul 18 02:33:06 EDT 2003


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Thursday, July 17, 2003, at 11:24  PM, Jeremy Hylton wrote:

> I think a useful pattern might be to manage the external resource in a
> non-persistent object with an __del__.  Use that object only for
> finalization.  I think you'd store that object in an _v_ attribute, so
> it doesn't get saved in the object pickle.  And you'd have to recreate
> the attribute every time __setstate__() was called.

This doesn't look suitable for my particular case, and the
__del__ approach seems too fragile.

I will have multiple objects in the ZODB referencing the
same file on disk. (Or I have multiple references to the same
object scattered around the ZODB tree - I don't care). What I
need is a way of deleting the file on disk when all of the objects
that use it are deleted from the ZODB, or a way of detecting that
all objects using that file have been removed.

Is there a way for an object to know how many references
there are to it stored in the ZODB? Can sys.getrefcount be
used for this purpose? I've run tests with an object acting
as a factory to generate these FileRefs, which keeps a
reference to the generated object. It can then look over
this list, doing a sys.getrefcount(ob) on each and doing the
cleanup if it is the last instance. This appears to work, but
I'd be interested in knowing how reliable this method would be.

I'm trying to avoid maintaining my own reference counts if
possible, as that way lies leakage. I'd rather not have to
write and maintain manage_beforeDelete hooks that trawl through
the soon-to-be-deleted object's data structures for these objects
if I can avoid it :-)

- -- 
Stuart Bishop <zen at shangri-la.dropbear.id.au>
http://shangri-la.dropbear.id.au/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (Darwin)

iD8DBQE/FsG6h8iUz1x5geARAtGHAJ9PAYEiyvatCT1nFxusC24YX9XOfgCgrFq3
moQLtkZDkWRfQ4x1XZwbpQM=
=o9DW
-----END PGP SIGNATURE-----




More information about the ZODB-Dev mailing list