Conference decalp::rtrnotes

685.0. "not transactional broadcast; reliable streams" by AMCFAC::RABAHY (dtn 471-5160, outside 1-810-347-5160) Mon Mar 17 1997 19:19

The other reason the world wants transactional broadcast is to reliably
distribute updates to a datastore.

So, given them what they want independent of transactional broadcast.  In fact,
if you do this and transparent multi-partition enqueue/send you don't need to do
transactional broadcast at all.

Transactional broadcast beyond these two functions is useless.

datastore 1	datastore 2	...	datastore n
-----------	-----------		-----------
update stat 1	update stat 2		update stat n
data item 1, 1	data item 2, 1		data item n, 1
data item 1, 2	data item 2, 2		data item n, 2
...
data item 1, k1	data item 2, k2		data item n, kn

An update is a generic operation that either;

	updates the value of a data item,
	deletes a data item,
	inserts a new data item

A reliable stream initially delivers an entire datastore at a known update stat
and then over time delivers all updates subsequent to the known update stat.  If
something disrupts the flow of updates then the reliable stream service simply
redelivers the entire datastore at a new known update stat and resumes
delivering updates subsequent to the new known update stat.

requester	server			subscriber
---------	------			----------------------
$dcl_tx_prc/req	$dcl_tx_prc/ser		$dcl_tx_prc/broadcast
					start:
					$start_tx
		$deq_tx			$enq_tx
		  DB select entire store
		$enq_tx/reply		$deq_tx
		$deq_tx			$abort
		  DB rollback
$start_tx
$enq_tx		$deq_tx
		  DB operation
$commit		$deq_tx
		  increment update stat
		  DB commit
		$enq_tx/broadcast	broadcast_AST:
					  if update stat is duplicate ignore
					  if update stat is missing goto start
					  update local copy of data store
		$deq_tx

The $enq_tx/stream is a best effort only.  If the system looses it a subsequent
stream message will reveal the gap and cause the subscriber to restart.

There's really nothing to do here but document the solution.