Conference decalp::rtrnotes

684.0. "not transactional broadcast; transparent multi-partition enqueue/send" by AMCFAC::RABAHY (dtn 471-5160, outside 1-810-347-5160) Mon Mar 17 1997 18:45

Ok, I've figured it out.  One reason the world wants transactional broadcast is
because it would give them transparent multi-partition enqueue/send.

So, give us what they want independent of transactional broadcast if that helps.

requester	server 1		server 2
---------	--------		--------
$dcl_tx_prc/req	$dcl_tx_prc/ser/key=1	$dcl_tx_prc/ser/key=2
$start_tx
$enq_tx		$deq_tx			$deq_tx
		  DB operation		  DB operation
loop:
$deq_tx		$enq_tx/reply		$enq_tx/reply
rollup
until_no_more:
$abort		$deq_tx			$deq_tx

Server 1 serves � the database, server 2 serves the other �.  Someone wants to
know the total across the two parts.  But we want to code this application to
handle a different number of partitions without recoding.  Replies should be
coded as a loop until no more.  The application will have to rollup the replies
into a final result.

Perhaps a new kind of server could do the rollups transparently to the requester?

requester	server 1		server 2		rollup server
---------	--------		--------		-------------
$dcl_tx_prc/req	$dcl_tx_prc/ser/key=1	$dcl_tx_prc/ser/key=2	$dcl_tx_prc/roll
$start_tx
$enq_tx		$deq_tx			$deq_tx
		  DB operation		  DB operation
								loop:
		$enq_tx/rollup		$enq_tx/rollup		$deq_tx
								rollup
								until_no_more:
$deq_tx								$enq_tx/reply	
	
$abort		$deq_tx			$deq_tx			$deq_tx

If there's only one partition then an $enq_tx/rollup degenerates to an
$enq_tx/reply and the trip to the rollup server is avoided?

The problem is coding an application to learn the number of partitions and where
the lines between them are is a pain.  It all gets worse if not impossible when
you want to consider transactional dynamic repartitioning.