RE: [bt-spec] URI issue subquestion #2

[Peter Furniss <peter.furniss@choreology.com>]

Jim,

The problem you describe was the flaw in the old system - where identifiers
were unambiguous within the scope of the addresses.  They in fact had to be
unambiguous in the scope of all the addresses the entity might migrate to.
That implied some mechanism for dispensing ids.

Which is why our proposal on issue 78 is to require the identifiers to be
*globally* unambiguous. Obviously if an identiifer is unambiguous
everywhere, it is unambiguous in all the places the entity might migrate to.
A hierarchical name scheme makes it easy enough for anything to allocate a
globally unambiguous identifier, and URI's as a whole are thus usable.

In practice, if server A allocates names that include an element that is
assigned to it, then if the entity migrates to server B, then server B will
need to have some sort of look-up (which might well have been needed at A as
well). But how that all works is private to A and B, which are of the same
implementation. It doesn't need to be standardised (unless someone decides
they want to standardise the recovery mechanisms, which is at least a very
long way down the road)

Yes, you could indeed use GUIDs, of whichever species. We propose that the
identifier be syntactically a URI, with the semantic requirement that be
globally unambiguous as an identifier of BTP transactions/inferiors etc. One
way of doing this would be to use the urn:uuid: namespace. Or you could use
an http: uri scheme, including the domain name of the machine it started on.
Or anything else.

Peter

> -----Original Message-----
> From: WEBBER,JIM (HP-UnitedKingdom,ex1) [mailto:jim_webber@hp.com]
> Sent: 02 February 2002 11:32
> To: Peter Furniss; LITTLE,MARK (HP-UnitedKingdom,ex1); BT - spec
> Subject: RE: [bt-spec] URI issue subquestion #2
>
>
> Peter:
>
> > We believe a migrating entity should have a name which is
> > invariant over all its migrations.
> > We believe it is a bad idea to allow an entity to change its name.
>
> This is a risky strategy. Imagine you have two transaction
> servers, A and B
> which provide fail-over fault tolerance for one another. Both are
> running a
> single transaction (for the sake of simplicity) and both have
> chosen the id
> "1" for those transactions (perhaps they are the first transactions to be
> run).
>
> Now imagine server A crashes and server B being available takes on its
> workload. It can't create another transaction called "1" because
> it already
> has one, which means that you can't always assume that the names you pick
> will be globally unique (unless you use some kind of qualifier in
> association with them).
>
> I guess you could mandate that an identifier is a GUID which means that
> name-crashes would be very unlikely?
>
> Jim
>