|Subject||Re: [Firebird-Architect] RFC: External Engine API|
> Vlad Khorsun escreveu:And it would return ... what ?
>>> Attachment and Transaction will be equivalent to Connection.
>> Why ? Are you going to disable multiply active transaction at one
>> attachment ?
> No, and that is the reason to have Attachment and Transaction instead of
> JDBC Connection.
> We create a method Attachment::startTransaction...
>>>> I like Vlad's idea of having special DPB/TPB parameters for a currentI implemented Alex's idea - Y-Valve passed its attachment\transaction handles
>>>> attachment/transaction more attractive. Do you have any objections to it?
>>> AFAIU, this requires TLS.
>> It is implemented in B2_1_ExecStmt branch and not requires TLS.
> I didn't reviewed it yet. Do it means something is passed in the DPB/TPB?
into lower level just after its creation and asked lower level for this handles when
needed. Two new internal API entries make the job GDS_SET_PUBLIC_HANDLE
and GDS_GET_PUBLIC_HANDLE. It is implemented by jrd8 subsystem only.
At jrd8 level passed handles is stored within corresponding objects -
Jrd::Attachment::att_public_handle and Jrd::jrd_tra::tra_public_handle
I know only drawback of this idea - there are no ability to use current context
inside ON CONNECT and ON TRANSACTION START triggers as at this time
Y-Valve have no handles created.
I have workaround in mind but it is hackish and i don't want to sound it now ;)
>>> But I have no problem to have this, also it's in my plans to have it.Savepoint is not a transaction. It would be confusion if the same code working
>>> It makes connection to database automatically usable in Delphi, for example.
>>> For the transaction obtained via special TPB, what should be the
>>> behavior of COMMIT and ROLLBACK? Should it act in a savepoint?
>> It is not allowed as transaction must be finished where it was started.
>> I.e. if client application started transaction - client application must finish it.
>> Another DBMS's may have own behavior, but in FB\IB it always worked
>> this way.
> But ISC API only closes transaction with commit or rollback, and current
> clients components do it.
> I suppose COMMIT/ROLLBACK in the server could work with savepoints, to
> not change user transaction.
with current context would start\finish savepoint but would start\finish transaction,
if working within own context. If user code needs savepoint it can create it explicitly.