Object lifetime in Firebird

From Jim Starkey:

Object lifetime is one of the two or three major strategic questions in
the merge between Firebird 2 and Vulcan. Almost all objects in Firebird
2 are deleted by pool deletion. To make this work, every resource
controlled by an object subject to delete-by-pool must also be pool
aware and allocated from the same pool. This makes writing object code
in Firebird difficult, time consuming, and fragile. It also makes
adoption of non-pool aware classes problematical at best. Vulcan still
has much of his code, but all new classes respect standard object
lifetime conventions, and none are "pool aware".

A question facing the project is whether or not we should accept object
oriented technology into our database implementation. If the answer is
yes, then I believe we must respect the integrity of objects and observe
individual object lifetime controls. This necessarily involves
rejection of the concept of delete-by-pool purposes other than
exceptional, localized mechanisms.

So where you and many other developers may say "of course, that's the
way objects work", in fact, that isn't the way Firebird 2 and
predecessors work.

I am arguing that post-merge object integrity be respected, a
pre-condition for adaptation of object technology. I am also arguing
that it is no longer necessary for all Firebird classes to be pool aware
and, in fact, most classes will not be. These questions seep into
almost every line of code in the prodct. I believe it better that we
resolve this question abstractly than as a debating point in the
general merge debate.

In my mind, the key technical questions around the merge are:

1. Object integrity (also known as delete-by-pool), including
obligatory pool awareness
2. The provider architecture
3. Object structured vs. flat configuration files
4. Thread synchronization primitives
5. The division of work between the Y-valve and the providers
6. Exception handling