Subject Re: [Firebird-Architect] Autonomous Transaction Routines
Author Jim Starkey
Adriano dos Santos Fernandes wrote:
> Jim Starkey wrote:
>
>> The implementation of commit retaining uses related transactions with
>> record visibility suitably fudged. The mechanism and fudge could
>> probably be extended to take autonomous sub-transactions visible to the
>> parent transactions.
>>
>>
> For what you want this?
>
> FWIW, the more useful thing would be if the autonomous block can see the
> preceding change from the parent.
> But this totally breaks the transaction control, as the autonomous block
> may commit and the parent not. I.e., this is READ UNCOMMITTED.
>
It does, indeed. But if the autonomous transaction sees the parent
transaction and the parent transaction rolls back, the autonomous
transaction can't commit. That leaves communication between a parent
and autonomous transaction is limited to formal parameters and local
variables.
>
>> If this discussion had started with a state of requirements rather than
>> a solution to an unstated problem, the choice might be easier.
>>
>> Gentlemen, may I suggest (again) that problems should precede solutions?
>>
> Sorry, but I'll not comment anymore on this type of comments from people
> that want FB to be stagnated without any other feature.
>
>
>
On the contrary, I would like to see Firebird as a functionality leader
in open source databases. However, I have some recent experience with
open source database projects with people hack in the first idea that
pops into their silly heads and the architectural disasters they leave
in their wake. Historically, the Firebird project has had a very strong
perspective on architecture, which I think is excellent. I would like
to see that tradition maintained, which is why I try to ask hard
questions. If you find you don't have answers, the fault is not with
the questions.

--
James Starkey, Senior Software Architect
MySQL Inc., Manchester, MA, USA, www.mysql.com
Office: 978 526-1376