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

[Alex P. <pes...@ma...>]

 On 03/28/11 18:28, Adriano dos Santos Fernandes wrote:
> 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.

What others things? Why evil?
When was openBlob in transaction?
> 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, 

With described approach I will not need casts.

> and at the same time make programs difficult to change from
> single to multidb transactions if needed.
>

There will be absolutely no difference in program when changing from
single to multiDbTransactions.
Except the start of transaction itself - but one will anyway need to
have >1 attachment, i.e. changes here are unavoidable. When multidb
transaction is started, one will work with it in exactly same way as
with single db. It's same interface, just different implementations.