OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: Batch as a Logical Unit of Work (was"Re: [provision] Comments on Draft 8 of the Spec...")


Okay, so my memory was fuzzy here.  I took a look at the very next 
paragraph in which I wrote that this "does not preclude a batch 
operation having transactional semantics".

Here's the whole thing:

*A batch is not a logical unit of work*. Using a batch operation to 
combine individual requests does _not_ imply atomicity (i.e., 
“all-or-nothing” semantics) for the group of batched requests. The 
failure of a nested request will _not_ undo a nested request that has 
already completed.
See Transactional Semantics <#_Transactional_Semantics>.

This does not /preclude/ a batch operation having transactional 
semantics—this is unspecified. A provider (or some higher-level service) 
with the ability to undo specific operations could support rolling back 
an entire batch if an operation nested within the batch fails. 

I'll change this to make it clear that we do not preclude transactional 
semantics but that none is specified.  I apologize for my confusion (and 
for any confusion that I caused).

Gary P Cole wrote:

> Bohren, Jeffrey wrote:
>
>>
>> 3.5.3.1 – ... Also change *A batch is not a logical unit of work* to 
>> *A batch does not need to be a logical unit of work*. We need to 
>> rework this paragraph to convey that a batch may or may not be a 
>> logical unit of work, but if it is, that is outside the bounds of the 
>> spec. The way it is written implies that it can not be a logical unit 
>> of work.
>>
> I believe that we agreed (during a conference call) to specify that a 
> batch should NOT imply a logical unit of work. As I recall, we decided 
> that any batch that implied a logical unit of work would be defined as 
> a separate capability. Rami Elron said there any batch operation that 
> implied a logical unit of work would require additional parameters and 
> options, and said that he might work on defining this capability.
>
> I believe this was the same conference call in which we decided that 
> batch requests must not be nested (that is, a batch request must not 
> contain a batch request). I think we even put it to a vote (or at 
> least asked whether anyone objected to the decision and *wanted* a 
> vote). Should we try to dig up some email or meeting minutes?
>
> I don't have any particular problem with rewording this section as you 
> suggest, but I hesitate to do so without remembering why we decided on 
> the current position. We *did* spend a fair amount of time and energy 
> discussing this issue back then.
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]