Branko =?ISO-8859-2?Q?=C8ibej?= <firstname.lastname@example.org> writes:
> 2) Cloning in parallel transactions
> Imagine we have a node at revision 11.17. Two clients want to clone the
> node at the same time: Client A in transaction 138547, and client B in
> transaction 138581. (Yes, all of those are primes. :-) )
> Now the questions:
> a) What will (should) be the node revision id's of the clones?
Whichever transaction clones the node first, will create the "next"
revision of 11.17, presumably 11.18. The slower transaction will
> b) How can we make sure (e.g., in the presence of aborted transactions)
> that we have no "holes" in the revision id's? I.e., that the next
> revision will be 11.18, not 11.19? Do we care?
> I'm sure I'm missing something very basic here ...
Nope, holes are almost a guaranteed thing. If the faster transaction
(above) aborts, then 11.18 is removed from the nodes table. No big
deal, there are holes. As long as node revisions are well-ordered and
can be quickly searched, holes don't matter.
Received on Sat Oct 21 14:36:19 2006