> Vlad Khorsun escreveu:
>>> 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...

And it would return ... what ?

>>>> I like Vlad's idea of having special DPB/TPB parameters for a current
>>>> 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?

I implemented Alex's idea - Y-Valve passed its attachment\transaction handles
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.
>>> 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.

Savepoint is not a transaction. It would be confusion if the same code working
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.

Regards,
Vlad