[Spread-users] Spread usage scenario for sending data

[Mayne, Peter]

I'm looking at Spread to implement a data replication scenario, but the
documentation is ambiguous enough that I can't tell is Spread is suitable or
not.

The scenario has a central shared database with (say) 30 client sites
sharing the data. Each of these client sites also has a site-specific
database that is shared with the central site. Each of the 31 sites can
update its own copy of the shared database and site-specific database, and
each night, changes are copied to the central site. (Ignore possible
conflicts for the purposes of this explanation.)

Spread would appear to be useful in that the client sites could fetch their
copy of the shared database changes in a sequence of reliably delivered
messages, and send their copy of the site-specific database changes
likewise.

My initial experiment with Spread doesn't look promising. I set up a Spread
daemon with two clients (spuser) in the same group, and sent messages
between clients using spuser's default SAFE_MESS. If a receiving client
dies, then further messages sent to that group are lost, which doesn't seem
very safe. Membership of a group appears to require the client being
connected, and the Spread daemon doesn't store the messages until the client
comes online.

The documentation makes it hard to figure out what is meant by "reliable".
It appears that my concept of reliable (JMS persistent messages, for
instance) isn't the same as Spread's. There's nothing wrong with that, but
I'm not sure what spread's definition of reliable is.

However, it appears that sending a list of changes via Spread, with the
currently off-line clients fetching them whenever they are able, is not
suited to the spread paradigm.

If the client sites connect to the central site and ask for updates since
the last time they connected, I'm not sure what extra benefit Spread
provides over and above a simple TCP connection between sites. (A slightly
provocative statement, but I'm trying to get educated. :-)

Comments? Thanks.

PJDM
-- 
Peter Mayne
Technology Consultant
Spherion Technology Solutions
Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602
T: 61 2 62689727  F: 61 2 62689777


The information contained in this email and any attachments to it:

(a) may be confidential and if you are not the intended recipient, any interference with, 
use, disclosure or copying of this material is unauthorised and prohibited; and

(b) may contain personal information of the recipient and/or the sender as defined 
under the Privacy Act 1988 (Cth). Consent is hereby given by the recipient(s) to 
collect, hold and use such information and any personal information contained in a 
response to this email, for any reasonable purpose in the ordinary course of 
Spherion's 
business, including forwarding this email internally or disclosing it to a third party. All 
personal information collected by Spherion will be handled in accordance with 
Spherion's Privacy Policy. If you have received this email in error, please notify the 
sender and delete it.

(c) you agree not to employ or arrange employment for any candidate(s) supplied in 
this email and any attachments without first entering into a contractual agreement with 
Spherion. You further agree not to divulge any information contained in this document 
to any person(s) or entities without the express permission of Spherion.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.spread.org/pipermail/spread-users/attachments/20040427/0fa6fc5a/attachment.html