[ZODB-Dev] How to predict George Bailey?

[Magnus Lycka]

At 20:33 2002-11-02 +0000, Toby Dickenson wrote:
>On Saturday 02 November 2002 1:13 am, Magnus Lycka wrote:
> > (As far as I see, only G.B'd
> > objects will cause closed windows.)
>
>Suppose some other concurrent transaction logically deletes an object for
>which you have an open window. You wont get exceptions immediately because
>the historical revisions will still be in the database.

Right. I meant in conjunction with undo. I close windows
today when an object is deleted. I catch this in the .remove()
method of a subclass of PersistentList and use the Observer
pattern. All windows subscribe to events changing or removing
objects of the class they are concerned with.

>However suppose the database is concurrently packed.

I don't pack the database with the application running.
Obviously the demands on a (for now) single user GUI
application is different from that of a web system like
Zope.

Even if we plan to make SystemSpecifyer (the latest
candiadate for a name) a multi-user system, I don't
think 24/7 is a requirement for us.

>Are you aware that there is a fundamental difference between the way you are
>using ZODB, and the usage patterns of Zope? Zope *never* holds on to an
>object reference across a transaction boundary. Im not sure whether this is a
>'rule' or merely a 'characteristic' (Jim?), but I think it has severe
>implications..... Check out the old threads about dangling references for
>examples of the problems that you are exposed to, but Zope is not.

I haven't analyzed Zope's source, but I imagined that this
would be the case. I have a fairly clear separation of the
GUI and the logic that manipulates the persistent objects,
but the GUI does have direct references to the persistent
objects. I've been thinking about placing GUI and logic in
different processes, partly to make it easier to "reboot"
the logic in case of an undo, but I never planned to close
down all object references on commit.

This is a system where a lot of objects might be visible
at the same time. Today we show all instances of a few
classes in tree widgets. In time, I suppose the described
systems might get very large, and then I think we'll have
to find ways to show only subsets, but we will certainly
have hundreds of objects on screen in some situations. Now,
we only have transaction boundries on explicit File->Save,
but we ought to have commits much more often. There are
things like recursive deletes that have to be handled as
one transaction, but typically, the transactions are small
and frequent.

It's an important consideration that these big trees don't
change any more on commit than they actually have due to
factual changes in the system.

I've basically built the applicaiton I would from a
perspective were I didn't have to think about persistence
or transactions at all, and tried to plug in ZODB in the
most unintrusive way. I wouldn't want it to be a monumental
effort to replace ZODB with another method of persistence,
such as a relational database.

I realize that ZODB was created for ZOPE, but I hope that
the ZODB developers want to make it useful for other types
of systems as well, even if this might mean other ways of
handling objects.

My client is talking about placing the code at sourceforge.
(I think the main problem there is to find a really good
name). We'll see if you get a chance to comment more in
detail onmy code indue time. (I'm sure there would be a lot
to comment on...)

>Ive detected similar cases by adding a special object as a _v_attribute, and
>used the __del__ of this object to detect deactivation. Maybe that would
>help?

Hm... Maybe. Thanks for the suggetion. But would this
help when an object is uncreated due to undo?


-- 
Magnus Lycka, Thinkware AB
Alvans vag 99, SE-907 50 UMEA, SWEDEN
phone: int+46 70 582 80 65, fax: int+46 70 612 80 65
http://www.thinkware.se/  mailto:magnus@thinkware.se