Subject | Re: [Firebird-Architect] Autonomous Transaction Routines |
---|---|
Author | Jim Starkey |
Post date | 2007-11-02T14:29:37Z |
Adriano dos Santos Fernandes wrote:
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.
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
> Jim Starkey wrote:It does, indeed. But if the autonomous transaction sees the parent
>
>> 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.
>
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.
>On the contrary, I would like to see Firebird as a functionality leader
>> 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.
>
>
>
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