On Thu, Feb 23, 2006 at 11:00:49AM -0500, Christopher Browne wrote:
> "Victoria Parsons" <victoria.parsons at streamshield.com> writes:
> > Is it really necessary, when creating a new set and subscribing it
> > that a wait for event is done after the set creation? Won't the
> > requests get queued and so are guaranteed to be processed on the
> > subscriber in the right order. The reason I ask is because I have a
> > single set currently replicating to many slaves. I want to add a
> > second set with a single table to go from the same master to all
> > slaves (with the intent of eventually performing a merge set). If
> > one of the slaves is temporarily down (network outage or turned
> > off), I want to be able to create the set on the master and issue a
> > subscribe set to all nodes, so that all the OK nodes pick it up
> > straightaway and when the bad node comes back it will process create
> > set, set add table, and subscribe set in the right order. By putting
> > a wait for event after the create set (and add tables) I won't be
> > able to subscribe any nodes until all including the bad one confirm.
> 
> Yes, you can have extra events "queued" up...
> 
> It basically introduces the risk that you might, if there is a problem
> with the slonik submissions, queue up a series of *bad* events, and
> have more complex cleanup to do if one of the early ones breaks.

Hrm... are there any error codes returned from a command? Or perhaps if
there was a way to tell wait to ignore certain errors. Basically, there
are conditions that won't create a mess to cleanup and those that will,
so it would be good if there was some way to differentiate (of course,
different people will have different ideas as to what a 'mess' is...)
-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby at pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461