Re: ! @%#/& BASE-PATH grrrrr!

Branko =?ISO-8859-2?Q?=C8ibej?= <brane@xbc.nu> 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
create 11.19.

> 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.

(Right, Jim?)
Received on Sat Oct 21 14:36:19 2006