| Subject | Re: [firebird-support] Re: Nested Transactions (you asked!) |
|---|---|
| Author | unordained |
| Post date | 2004-07-09T20:10:45Z |
Alexander,
As I don't use savepoints in FB, nor any systems that support sub-transactions, I'm afraid I only
have contrived examples to provide. (Aside: as I recall, postgresql just recently got money from
some company to develop several features, including subtransactions -- something on slashdot
anyway.) Under the circumstances, I can't prove this is a "must-have" feature, rather than a "build
and they will come" feature. (In that regard, were savepoints necessary? You could always undo the
whole transaction and redo from the start -- that didn't prevent them from being implemented
anyway.)
The general idea though involves this: some event (A) causes our user to start doing several things
at once. In order to make greatest use of the databases's constraint system, we wish to do
everything in the database immediately, rather than queueing it up on the client/app side. (Doing
so generally requires implementing business rules on both ends to let the user know what can or
can't be done -- why are we duplicating that work?) The user wishes to save all the work done
together, or not at all (standard transactional semantics) but wishes to have 'undo' functionality
for each part of the work being done. She may want to back up in a wizard screen (undoing what a
few of the pages have done) -- that can be done with savepoints. But savepoints will not allow her
to be working her way through, say, two wizard screens at the same time. If she backs up in one, it
will have to undo some of the work in the other. Two individual transactions would allow this, but
cannot be committed/rolled back together as a block.
From having coded too many record screens, special screens, and wizards ... many of which include
functionality from others -only- because the user needed to know that changes would be undoable
together ... I very much wish for a "transaction environment". I'm invisioning a sort of desktop in
which all actions, regardless of order, take place on a single master transaction. You can undo
individual bits without affecting others (unlike savepoints,) with the safety (in mind) that you
can undo everything together if you need to. Committing a transaction inside the environment would
make those changes visible locally to other sub-transactions, but would not be absolutely final.
It's an idea, but I (and my users) have survived without. Perhaps we could ask the originator of
this thread why he/she initially asked if Firebird supports this? Was it need, convenience, or just
curiosity? If anything but curiosity, was there an example to support it?
[If transactions were generalized enough, I think we'd eventually run into split/join semantics. I
haven't studied them enough to know whether or not they're logically consistent. But generally when
I see an item, I see a sequence, then a tree, then a graph (and sometimes an unordered collection
in there too.) Some systems barely have single items, Firebird has the sequence, I'm thinking a
tree would be useful, and I just see the graph coming eventually. That's where split/join would
appear -- but again, I'm not sure how correct they are, nor how we'd go about using them even if we
had a vague sense we needed them.]
-Philip
---------- Original Message -----------
From: "Alexander V.Nevsky" <ded@...>
To: firebird-support@yahoogroups.com
Sent: Fri, 09 Jul 2004 17:06:23 -0000
Subject: [firebird-support] Re: Nested Transactions
As I don't use savepoints in FB, nor any systems that support sub-transactions, I'm afraid I only
have contrived examples to provide. (Aside: as I recall, postgresql just recently got money from
some company to develop several features, including subtransactions -- something on slashdot
anyway.) Under the circumstances, I can't prove this is a "must-have" feature, rather than a "build
and they will come" feature. (In that regard, were savepoints necessary? You could always undo the
whole transaction and redo from the start -- that didn't prevent them from being implemented
anyway.)
The general idea though involves this: some event (A) causes our user to start doing several things
at once. In order to make greatest use of the databases's constraint system, we wish to do
everything in the database immediately, rather than queueing it up on the client/app side. (Doing
so generally requires implementing business rules on both ends to let the user know what can or
can't be done -- why are we duplicating that work?) The user wishes to save all the work done
together, or not at all (standard transactional semantics) but wishes to have 'undo' functionality
for each part of the work being done. She may want to back up in a wizard screen (undoing what a
few of the pages have done) -- that can be done with savepoints. But savepoints will not allow her
to be working her way through, say, two wizard screens at the same time. If she backs up in one, it
will have to undo some of the work in the other. Two individual transactions would allow this, but
cannot be committed/rolled back together as a block.
From having coded too many record screens, special screens, and wizards ... many of which include
functionality from others -only- because the user needed to know that changes would be undoable
together ... I very much wish for a "transaction environment". I'm invisioning a sort of desktop in
which all actions, regardless of order, take place on a single master transaction. You can undo
individual bits without affecting others (unlike savepoints,) with the safety (in mind) that you
can undo everything together if you need to. Committing a transaction inside the environment would
make those changes visible locally to other sub-transactions, but would not be absolutely final.
It's an idea, but I (and my users) have survived without. Perhaps we could ask the originator of
this thread why he/she initially asked if Firebird supports this? Was it need, convenience, or just
curiosity? If anything but curiosity, was there an example to support it?
[If transactions were generalized enough, I think we'd eventually run into split/join semantics. I
haven't studied them enough to know whether or not they're logically consistent. But generally when
I see an item, I see a sequence, then a tree, then a graph (and sometimes an unordered collection
in there too.) Some systems barely have single items, Firebird has the sequence, I'm thinking a
tree would be useful, and I just see the graph coming eventually. That's where split/join would
appear -- but again, I'm not sure how correct they are, nor how we'd go about using them even if we
had a vague sense we needed them.]
-Philip
---------- Original Message -----------
From: "Alexander V.Nevsky" <ded@...>
To: firebird-support@yahoogroups.com
Sent: Fri, 09 Jul 2004 17:06:23 -0000
Subject: [firebird-support] Re: Nested Transactions
> --- In firebird-support@yahoogroups.com, "unordained"------- End of Original Message -------
> <unordained_00@c...> wrote:
> > The main difference between the two is the concurrency of child
> transactions. With sub-
> > transactions, you could initiate multiple sub-transactions and work
> on all of them simultaneously.
>
> Sorry, but in this sense I don't understand why do you need
> _sub_transactions. This is exactly the way of usage of transactions.
>
> Best regards,
> Alexander.
>
> ------------------------ Yahoo! Groups Sponsor --------------------~-->
> Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
> Now with Pop-Up Blocker. Get it for free!
> http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/67folB/TM
> --------------------------------------------------------------------~->
>
> Yahoo! Groups Links
>
>
>