Re: [Firebird-devel] Providers, yvalve, external engines and object lifecycle

[Adriano d. S. F. <adr...@gm...>]

On 27-03-2011 09:57, Alex Peshkoff wrote:
>  On 03/25/11 21:16, Adriano dos Santos Fernandes wrote:
>>
>>> Let's suppose that user implemented some helper around IAttachment*,
>>> which is not refCounted as you wish. Please explain, how must behave
>>> that object when detach is requested, but there are some other threads,
>>> using that object.
>>>
>> Let me first say something about your refcounted approach:
>>
>> Current, when an user detachs and attachment, all handles related to it
>> and not-yet-freed are closed.
>>
>> Let say you did the same when calling IAttachment::detach. Then your
>> refcount don't work, cause it will wipe pointers to objects with references.
>>
>> Let say it don't free the subobjects. Then you're making a common
>> situation (close a parent -> close children) to leak memory.
>>
>> Now about your question, more directly. If this thread is doing
>> something inside the yvalve, the detach may (*internally) decrement a
>> refcounter and don't free the object, so we don't see a crash inside the
>> yvalve. As soon the yvalve release this reference, the object is wiped.
> 
> This is wrong suggestion. We must return correct status value from
> detach, but what can we return if we just decrement refcounter? And what
> should we do when we try to do real job, but something goes wrong?
> This is specially well seen on a sample with commit and some error
> thrown when doing DFW.
> 
No, Alex. We don't delay the detach in the provider object. We delay
"delete this" on the yvalve object. And since the user access always via
the yvalve object, the refcounting on the provider object becomes
unnecessary too.

> Another approach that will sooner of all work is when
> detach/drop/commit/etc do not dispose/release an object. This must be
> done explicitly, i.e. the sequence of calls is:
> 
> ITransaction* tra = att->startTransaction();
> // do some job with that transaction
> tra->commit();
> tra->dispose();
> 
> This works, but looks bad for ST appliactions.
> 
Don't think this is ok. We need dispose for things who only need
dispose, and we don't need it in objects that must be freed by another ways.

>> Note we don't need any effort to support this. As soon we remove
>> addRef/release from IInterface, we can make YAttachment and friends to
>> inherit from RefCounted and IAttachment and friends.
>>
>> So I insist, moving addRef/release to the API fixes nothing and only
>> complicate things. Transactions has no release, it's freed by
>> commit/rollback. Attachments has no release, it's freed by detach/drop.
>> There is no reason to insert a release function in them that sometimes
>> do a thing (decrement a refcounter) and sometimes do another (rollback
>> or detach).
> 
> What to do if release/dispose is called for not detached/committed
> object is really hard question.
> The most logical way is to treat death of the object from
> release/dispose exactly like from process exit.
> And this is in accordance with at least OLE DB standards.
> 
It's hard question but has simple answer. Objects which has
commit/rollback or detach/drop should not have release.


Adriano