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

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

On 28-03-2011 15:18, Vlad Khorsun wrote:
>     Let me comment a bit.
> 
>>>>> If external code start transaction, using legacy handle created for
>>>>> current attachment, then isc_start_transaction(legHandle) will find
>>>>> IAttachment* curAtt, appropriate for that legHandle, and call
>>>>> curAtt->startTransaction(). Certainly, if curAtt is not yValve's but
>>>>> engine's object, this means that transaction is started not under yvalve
>>>>> control. And telling true I see absolutely no problems that this
>>>>> transaction did not pass through yValve.
>>>>>
>>>> I do not agree this is easy or make code simple. 
>>>
>>> Many times simpler than adding artificial yValve control interface.
>>>
>> It's becoming difficult to discuss with you cause you change your
>> opinions everytime. Yesterday you said:
>>
>> ------------------
>>> In my new version of why.cpp things like CAttachment (C*) classes gone
>>>> in favor of YAttachment (Y*) objects. Things are much simple and
>>>> effective, became directly usable without legacy handles, may use the
>>>> same API (semantics defined in yvalve) for client and external code
>>>> running on the server.
>>>>
>> Looks like I totally agree with mentioned changes. I suppose you also
>> have a module to translate ISC API calls?
>> ------------------
>>
>> You also agreed with these now "artificial yValve control interface" a
>> number of times, and also disagreed with them a number of times....
> 
>     Alex (and me) disagree with IProviderManagement interface.
> 
>>> Your solution to pass pointers to yValve objects into engine when
>>> working with ISC  API was unavoidable hack when using ISC  API. With new
>>> providers interfaces we should avoid such hacks. Removing old (or new)
>>> hacks is one of the reasons to add new interface. I do not understand
>>> why do you protect that old hack so intensively, and try to push it into
>>> new code.
>>>
>> I don't know exactly what are you talking about.
> 
>     I believe Alex means
> 
>         FB_API_HANDLE Attachment::att_public_handle, and 
>         FB_API_HANDLE jrd_tra::tra_public_handle
> 
> 
Looks like you miss the place I liked the solution to make the engine
call the yvalve to register handles. Of course, yvalve must publish
yvalve objects for external usage.

This still lacks support for providers wanting to do some sort of
chaining. But this is another problem, and would be necessary to
investigate separated if required.


Adriano