When XOTcl exits, it seems that the [destroy] method is called on all objects. The first question is whether this is wise .. possibly. The problem is I would like to build a transparent layer for persistence storage which could be applied to a wide range of applications. The problem naturally is that the objects in the persistence storage get destroyed when the application exits :-)
Kristoffer,
I hit the same problem in a persistent application I am working on. My solution is to define a new method, delete, that destroys the object and deletes the object from the persistent storage. Just destroying the object does not delete it from persistent storage.
Instead of explicitly calling destroy on objects, I just call delete. My persistence layer is snapshot based, but delete instantly deletes the persistence for an object. This has the problem of a shrinking set of persisted objects between snaphots.
Have you worked with prevayler(www.prevayler.org)? In my java days I used this for a while. I'd like to make a port of this to xotcl one day.
Ben
On 01/02/06, Kristoffer Lawson setok@fishpool.com wrote:
When XOTcl exits, it seems that the [destroy] method is called on all objects. The first question is whether this is wise .. possibly. The problem is I would like to build a transparent layer for persistence storage which could be applied to a wide range of applications. The problem naturally is that the objects in the persistence storage get destroyed when the application exits :-)
/ http://www.fishpool.com/~setok/
Xotcl mailing list Xotcl@alice.wu-wien.ac.at http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
-- Lao Tsu said: When the fool learns the Way, He laughs at it. Yet if the fool did not laugh at it, It would not be the Way. Indeed, if you are seeking the Way, Listen for the laughter of fools.
Kristoffer Lawson schrieb:
When XOTcl exits, it seems that the [destroy] method is called on all objects. The first question is whether this is wise .. possibly.
well, it was some work to do so, and i think this is important from the oo-point-of-view. If one allocates "external resources" (e.g. temp-files, register on a whiteboard, etc) and deallocates these resources in a destructor, the deallocation should certainly happen, when the program exists gracefully.
The problem is I would like to build a transparent layer for persistence storage which could be applied to a wide range of applications. The problem naturally is that the objects in the persistence storage get destroyed when the application exits :-)
a strong coupling of the destruction of an xotcl object with its persistent representation is often not a good idea. For example, in the aolserver, persistent objects will be used in connection threads, which are created/terminated based on demand.
note, that also the creation of objects is in the persistent situation different. When one creates a new object, it is expected to be in a freshly initialized state. In the persistent case, you might want do decide, wether you want a fresh persistent object, or a refetched object from the last checkpoint. I use normally a fetch and delete method. You can still call e.g. delete from the destructor if you need it....
-gustaf
/ http://www.fishpool.com/~setok/
Xotcl mailing list Xotcl@alice.wu-wien.ac.at http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
Gustaf Neumann wrote:
Kristoffer Lawson schrieb:
When XOTcl exits, it seems that the [destroy] method is called on all objects. The first question is whether this is wise .. possibly.
well, it was some work to do so, and i think this is important from the oo-point-of-view.
Some work to enable? The general deletion of a Tcl interpreter will call any associated deletion callback for AssocData and commands. The one exception is for the last interpreter in a "common" shell environment, which doesn't get deleted normally (unless exit is undefined or you compile with -DPURIFY).
If one allocates "external resources" (e.g. temp-files, register on a whiteboard, etc) and deallocates these resources in a destructor, the deallocation should certainly happen, when the program exists gracefully.
The graceful deallocation argument is mostly spurious, as the OS cleans things up on program exit, but freeing of external resources is important. This is why I'm considering fixing that "last interp" exception above.
Jeff
Jeff Hobbs schrieb:
Gustaf Neumann wrote:
Kristoffer Lawson schrieb:
When XOTcl exits, it seems that the [destroy] method is called on all objects. The first question is whether this is wise .. possibly.
well, it was some work to do so, and i think this is important from the oo-point-of-view.
Some work to enable? The general deletion of a Tcl interpreter will call any associated deletion callback for AssocData and commands. The one exception is for the last interpreter in a "common" shell environment, which doesn't get deleted normally (unless exit is undefined or you compile with -DPURIFY).
i am quite satisfied with the current behavior of tcl. we have various compile flags already in xotcl to control the behavior, mostly for debugging memory leaks etc. (not unisimilar to the -DPURIFY motivation in Tcl core). And yes, we are treating "interp exit" and "last interp exist" differently internally.
If one allocates "external resources" (e.g. temp-files, register on a whiteboard, etc) and deallocates these resources in a destructor, the deallocation should certainly happen, when the program exists gracefully.
The graceful deallocation argument is mostly spurious, as the OS cleans things up on program exit, but freeing of external resources is important.
exactly.
This is why I'm considering fixing that "last interp" exception above.
i am not sure that this would simplify the xotcl exit behavior significantly. The biggest problem was to get the deletion order within a namespace correct. since objects and classes are cmds in a namespace's has table, standard tcl deletion does not care about the deletion order. xotcl has to care about this: if we have for example in a namespace
Class A Class B -superclass A B create b1
we have to destroy first object b1 (since this will call the destructor methods of Class B and A as well), and then the classes A and B. This is slightly more complicated with nested namespaces. Therefore xotcl has to create a topological order from the set of destroy candidates, call the destructors in this order and delete the c-structures in a second round. Btw, a similar topological order is used by the serializer.
best regards -gustaf
-
Ben Thomasson -
Gustaf Neumann -
Jeff Hobbs -
Kristoffer Lawson