Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Python (http://www.velocityreviews.com/forums/f43-python.html)
-   -   python destructor (http://www.velocityreviews.com/forums/t954206-python-destructor.html)

Ferencik Ioan 11-05-2012 06:51 AM

python destructor
 
Hello there folks,

I have a bit of a special issue.
I'll start by disclosing myself for what i am doing. I am a postgraduate student and I really have good reasons to do what I am doing. At least i think so.

And not the issue.
I am building a python web service. This web service has some generic objects and I use a metaclass to customize the classes.
Second I use a non-conventional object oriented database, dybase

(http://www.garret.ru/dybase/doc/dyba...l#introduction)

Now these is a OODBMS claiming to support ACID transactions.


The instances of my objects are recursively organizing themselves into a hierarchical tree-like structure. When I make an instance of this object persistent dybase actually can recursively save all tree structure.
Everything works well here.

I altered the main class situated at the root of my class hierarchy to actually store inside the__dict__ not the instances of its children but their unique ID's. Then when I set a child attribute I create it and instead of being stored in the instance the child goes to a database index object. Thus it becomes Universally addressable. The a parent retrieves the child it actually fetches it from the database.
In this way I ended up with very small objects.However these objects can regenerate the treelike structure as if they were storing there children in the __dict__.

The issue is how to give the instances access to the database and properly handle the opening and closing of the database.
It seems futile to me to actually open/close the connection through a context. Because the database is a file it will issue an IO operation on every attribute access and we all know __getattribute__ is used extremely often.
For this reason I thought the best way would be to wrap the dybase Storage (main class) into a local storage version which would have __del__ method.
The local Storage is a new style class..it opens the DB file but the __del__ is never called.
This is because the Storage class has at least 2 cyclic references.
So my Storage class never closes the database. I would like this class to close the database when it is garbage collected.
The class is a Singleton FYI as well but this might not be relevant or evennecessary.
So my question is:
what s the best way to force __del__ on a singleton that has cyclic references. Should i use weakref and alter the original source? Is there a way i can force a singleton to garbage collect itself?.

I am by no means a software engineer so i would appreciate any advice from some experts on the matter.
Thank you in advance.







Ferencik Ioan 11-05-2012 09:07 AM

Re: python destructor
 
On Monday, November 5, 2012 8:51:00 AM UTC+2, Ferencik Ioan wrote:
> Hello there folks,
>
>
>
> I have a bit of a special issue.
>
> I'll start by disclosing myself for what i am doing. I am a postgraduate student and I really have good reasons to do what I am doing. At least i think so.
>
>
>
> And not the issue.
>
> I am building a python web service. This web service has some generic objects and I use a metaclass to customize the classes.
>
> Second I use a non-conventional object oriented database, dybase
>
>
>
> (http://www.garret.ru/dybase/doc/dyba...l#introduction)
>
>
>
> Now these is a OODBMS claiming to support ACID transactions.
>
>
>
>
>
> The instances of my objects are recursively organizing themselves into a hierarchical tree-like structure. When I make an instance of this object persistent dybase actually can recursively save all tree structure.
>
> Everything works well here.
>
>
>
> I altered the main class situated at the root of my class hierarchy to actually store inside the__dict__ not the instances of its children but theirunique ID's. Then when I set a child attribute I create it and instead of being stored in the instance the child goes to a database index object. Thus it becomes Universally addressable. The a parent retrieves the child it actually fetches it from the database.
>
> In this way I ended up with very small objects.However these objects can regenerate the treelike structure as if they were storing there children inthe __dict__.
>
>
>
> The issue is how to give the instances access to the database and properly handle the opening and closing of the database.
>
> It seems futile to me to actually open/close the connection through a context. Because the database is a file it will issue an IO operation on everyattribute access and we all know __getattribute__ is used extremely often.
>
> For this reason I thought the best way would be to wrap the dybase Storage (main class) into a local storage version which would have __del__ method..
>
> The local Storage is a new style class..it opens the DB file but the __del__ is never called.
>
> This is because the Storage class has at least 2 cyclic references.
>
> So my Storage class never closes the database. I would like this class toclose the database when it is garbage collected.
>
> The class is a Singleton FYI as well but this might not be relevant or even necessary.
>
> So my question is:
>
> what s the best way to force __del__ on a singleton that has cyclic references. Should i use weakref and alter the original source? Is there a way ican force a singleton to garbage collect itself?.
>
>
>
> I am by no means a software engineer so i would appreciate any advice from some experts on the matter.
>
> Thank you in advance.


Just in case somebody is interested:
Because my Storage is a singleton I registered the close() method with atexit from the Storage open().

This actually closes the connection. Not sure if this is feasible but it WORKS!

I am using mod_wsgi in daemon mode so I have multithreading issues. If I configure the mod_wsgi with one process dybase works correctly.
I have to override the Persistent.store() and make it thread safe using multiprocessing. This is for ANYONE who uses or plans to use dybase in a web environment.


All times are GMT. The time now is 01:04 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.