Leyne, Sean wrote:

>> The earlier discussion of temporary tables
>>provides a general architecture for mapping a relation to a different
>>file.
>>
>>
>
>Doesn't this in-memory structure and the earlier implementation
>discussions mean that FB would never be able to work in
>clustered/fail-over environments?
>
>

Failover keeps a database accessible when a node leave the cluster. It
doesn't preserve any uncommitted work on that server. Loosing a
pre-deleted temporary file is a feature, not a bug.

Great gobs of work have been in architectures that sync ongoing
processes for failover, for example, Tandem's Non-Stop system. Even it
required that cooperating processes on different processors periodically
exchange state. Failover, obviously, could resume only from the context
of the most recent exchanged state.

To the best of my knowledge, nobody has ever attempted to build a system
where an active transaction could failover in a cluster envirornment.
Short of having several processors executing in lock-step mode (an utter
impossibility these days), I can't imagine how it could be done.

>By creating additional files wouldn't this further increase the
>co-ordination required between the cluster nodes?
>
>

No, since by definition, a file containing transient data is, well,
transient. When its session (attachment) goes away, the data properly
goes poof.

>Whereas, by adding the data to the existing db file would mean that the
>TDS would fall under the standard db 'coordination' activities.
>
>

Nope.

>Shouldn't those environments be considered when discussing/considering
>new features? (They are a growing presence in IT shops)
>
>
>

No, I don't think so. If anyone want to define "cluster" we can discuss
features in term of impact of said clusters. If cluster means some
future as yet undefined architecture it's a little difficult to nail down.

I use the term cluster as defined by DEC: a collection of independent
processors sharing peripherals (i.e. disks) coordinated by a common lock
manager. This means, specifically, no shared memory. It doesn't
preclude point to point communication between nodes, but it doesn't
depend on it either.

There are other perfectly valid definitions of cluster, but their
characteristics derive from their definitions, not their name. So, Mr.
Leyne, Sean, if you could be so kind as to define what you mean by
"cluster", we can talk about the ramifications of this and other designs.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376