RE: Bulk Transactions

I support the atomicity requirement since commands in the bulk message
aren't dependent on each other.  If there are commands that are dependent on
each other then they should be packaged together in some way.  As far as
reporting the results, the single message reply could contain individual
replies for each of the commands.  One reason for the bulk message is to
improve performance while still being subject to the serial transaction
model.  Here, I don't have any dependencies between multiple commands, but
want to send them all at once without having to wait for the response before
sending the next one.
 
I don't have an opinion on the 2nd issue of message design.

-----Original Message-----
From: avri [mailto:[email protected]] 
Sent: Thursday, June 26, 2003 07:13
To: [email protected]
Subject: [GSMP] Bulk Transactions





This mention of bulk messages reminded me that there 

was a requirement: 

2.7.2. Bulk Transactions 

in the requirements draft. 


I have a question about these. 

not about their importance, but about their atomicity. 


Currently we have only one error code in a message. 


So, do we consider a bulk message a single action? 

this would mean that if even one of the transactions failed, 

the entire command would fail. 

in order for state to be determinate, this would mean the 

switch would be responsible for undoing any transaction 

that had been completed. 


Or are we saying that we need for each transaction to be 

an atom it is own right and thus each one will need its own 

error code. 


I tend toward the former, thus placing the burden of being able 

to guarantee to undo any changes on the switch. And if the 

switch is not equipped to do so, it should reject bulk transactions. 


Another questions i have: 


- Do we modify existing messages to support 

bulk transactions or do we create new messages. 

- and if so what needs to be bulk enabled: 

- add is obvious 

- reservation 

- or is the triggered add i wrote about sufficient if 

it has the bulk transaction capability, with an 

individual reservation message needed prior 

to each transaction. 


I tend toward the third possibility. 


Comments on both issues please! 


a.