Hi! Lets call YBlob::cancel, YTransaction::commit, YTransaction::rollback, YEvents::cancel and maybe others as "destroy methods".
Destroy methods when called in y-valve objects automatically does a "release" on them. So you have: IBlob* blob = ...->openBlob(...); blob->cancel(); // no leak On the other hand, in engine provider, destroy methods does not release the objects: IBlob* blob = ...->openBlob(...); blob->cancel(); // leak blob->release(); // no leak I think the release/no-release semantics must be an interface contract, and all implementations must respect it. For example, currently we have InternalDS and IscDS classes that today (after providers are created) are pretty redundant. Some day they could be merged. But if one works directly with engine provider (like now) and another works with y-valve, we'd need very non-intuitive code to manage this. Adriano ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
