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/dybase.html#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 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 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.
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. -- http://mail.python.org/mailman/listinfo/python-list
