Re: [Vrs-development] Dynamic GW domain table

[Chris Smith]

On Thursday 25 July 2002 21:00, Eric wrote:
> I suppose I could envision functionality in the cluster manager that
> receives requests from running programs for particular services,
> discovers domains providing those services by talking to other CM's,
> and swaps those domains in to slots in GW's domain table.  It would
> also have to keep track of the connectness of the entire VRS to avoid
> partitioning (one group of nodes getting completely disconnected from
> another group).

There are probably better way to achieve this without having to swap slots...
which is complicated because you have a GWService table which indexes a 
GWDomain table which references particular machines.....
Swapping slots means hacking about with the service table!  No-can-do.

> And as you point out, the distributed filesystem will complicate
> things a little bit.  Any filesystem-modifying operation (eg write())
> must be synchronized among the various nodes that either store the
> virtual sector in question, are reading it, or are writing to it.
> That means that all those nodes will have to be swapped in to slots
> in GW's domain table before the write can complete, and that the
> write will block or fail if there aren't enough slots to swap all the
> nodes in.  (Talk about a slow filesystem. :-)

Slow.  Exactly.  Goldwater is designed to be FAST, safe and manageable!
Not to do dynamic discovery was an early design decision.
I'm positive I/we can solve the finite-number-of-domains-per-LDS problem, 
even if it's worked around under the cover so that it is no longer a problem.
[Actually the plan I have is based on the introduction of anonymous domains 
(when a new LDS comes to the VRS, every LDS admin does NOT want to have to 
enter it's details into their config!) I want to add a new GWAPI function to 
allow anonymous domains to be added dynamically.  This would be controlled by 
the CM and driven by the 'LDS-Subscribe/Unsubscribe to VRS' admin command].


This is where my great plan for TP within goldwater comes in.
I *know* I'm just going to have to buy the OpenGroup papers on this (as they 
document the API used by Oracle, Tuxedo (which goldwater is getting to look 
like from a distant hill) and others).

Thus multiple GWService calls can be sectioned into a single atomic 
transaction.  We (as application developers) need to make sure that the final 
commit at our ResourceManager 'module' does what it's supposed to do when 
asked to.  Not a trivial task, but the whole transaction management should be 
left to the middleware (which means that transactions can span multiple 
resources including databases if we so wish).

We cannot do table swapping whilst transactions are in progress,  so this 
means huge amounts of contentious blocking!


-- 
Chris Smith
  Technical Architect - netFluid Technology Ltd.
  "Internet Technologies, Distributed Systems and Tuxedo Consultancy"
  E: address@hidden  W: http://www.nfluid.co.uk