Re: [Vrs-development] IBM Token Ring Thingy...

[Chris Smith]

On Saturday 04 May 2002 00:04, Bill Lance wrote:
> --- Eric Altendorf <address@hidden> wrote:
> > If we want to guarantee that the CI remains
> > consistent, or remains "at most X
> > minutes out of date" or anything else, I think we're
> > going to have to resort
> > to transactions.  Pretty much ANY time we want to
> > make a guarantee about data
> > consistency across a distributed network, we're
> > going to have to use
> > distributed transactions with two phase commit.

Okay - there are two distinct 'sections' to the VRS.
One is the Cluster Manager, the other is the Resource Manager.

It might very well be that we need to employ transactions for the RM, but I'm 
not entirely sure that we need them for the CM.  As far as I am proceeding at 
the moment, it doesn't matter if there are greater or fewer nodes in the VRS 
than a particular LDS thinks.... 

However, the Resource Manager tables MUST be up to date, otherwise resources 
cannot be accessed/updated.  This probably will require some sort of 
transaction processing (either commit all, or none).

BTW Goldwater is loosely based on BEA Tuxedo (it began five years ago as a 
simple BEA Tuxedo stub so I could work from home (tux wasn't available for 
Linux/FreeBSD at the time)).

Tuxedo inherrently supports transactions (X/Open XA Transaction Processing) - 
it's possible that I could engineer Transaction Logging into Goldwater, but 
we'd have to write the 2PC support into our LDS application and 'bind' it to 
the Goldwater TP API.  This 2PC 'stub' could be provided as an library which 
applications can import and bind to.  Food for thought.

This way, you'd begin a transaction, call GWServices at all the LDS's you 
need to, then commit the transaction.  A Failure of any one of the GWService 
calls would rollback the transaction.  If an LDS won't rollback, it is marked 
as BAD and will require manual intervention.  Any GWService call may be 
marked as 'non-transactional' and as such will not participate in the current 
transaction.

But you're correct - Transaction Processing is hideously complicated, which 
is why I haven't implemented it yet - plus I've not had a use for it so 
far......

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