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

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

On 28-03-2011 06:10, Alex Peshkoff wrote:
> 
> This need happened due to my attempt to emulate old ISC API too careful :-)
> All the cases when we need both attachment & transaction are due to my
> wrong understanding (when writing interfaces for yvalve) of how should
> multiDb transaction work.
> Such transaction should have same interface as single database one, but
> absolutely other implementation. This implementation is
> provider-independent, therefore can be placed in master interface.
> startMultiDbTransaction() creates a container holding pairs -
> IAttachment* which started transaction and started ITransaction*. All
> functions like createBlob() go to ITransaction. Normal implementation
> ignores IAttachment* parameter. MultiDb implementation searchs in
> internal container for appropriate IAttachment* and calls same function
> for found transaction. No more casts - and therefore no need in
> additonal checks. And yes - one can safely mix attachments, created by
> different providers, in such MultiDb transaction.
> 
> I.e. I still do not see where do we need to do additional checks.
> 
The scheme of put openBlob and others in transaction was very evil, and
complete different than the way others things worked.

With it, you created this notion of passing a null attachment. But you
would need it in multidb transactions, then, you would still need the
casts, and at the same time make programs difficult to change from
single to multidb transactions if needed.

>>>> Also, let say external code receives an engine IAttachment which was
>>>> registered in yvalve and now has a handle. Then external code starts to
>>>> use this handle and start new transaction with legacy API. If this
>>>> IAttachment is not from yvalve, now yvalve gained another responsibility
>>>> which is to coordinate engine provider objects.
>>> 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....

>> Using "YObjects" in the
>> yvalve makes sense, and this case introduces an exception that makes
>> things harder.
> 
> I do not understand what this phrase about? What "YObjects", how makes
> sense?
> 
> 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.


Adriano