views:

16

answers:

2

Is there a compelling reason to offer "batch update" version of update methods in a .NET web service?

Is there a considerable advantage over making multiple calls, asynchronous or synchronous, over HTTP?

My first impulse is to offer asynchronous calls and include a record ID in the input composite, and to push-back on the requirement to offer batch operation as a micro-optimization. Alternatively, I would request the consumer to use an iterative loop and make multiple calls.

I don't wish to make a poor suggestion.

+1  A: 

I believe the reason for offering "Batch Updates" is to reduce transaction load on your Database Server. That said, if this isn't a concern, I wouldn't bother offering one.

Nate Bross
I was thinking this, yes, although writing the update into a single statement is overly complicated for this application. I also was thinking that their concern was for transmission of extra XML headers, but if they are really sending that much data, they will need to be fiddling with the message buffers etc. in WCF too. Your answer is leaning me further towards pushing this requirement back to the user as premature optimization.
Eugarps
+1  A: 

We offer createRecord() and createRecordAsync() / createRecordCompleted (an event handler)

We toyed with the idea of creating a createRecordBatch() for about 10 seconds before we started to notice problems with it. Our createRecord() method takes in, amongst other things, a session ID, a creatorHandle for the user, and a string array containing all values. To implement a batch load, we would have to create a two-dimensional array for values, an array to store creatorHandle, and a single session ID.

Even so, our web services just act as a wedge between our external vendors and our core application. The core application does not support batch loads. Essentially what we would have been doing was mimicking a batch load to our vendors. We would have to parse their batch data into individual record creations. There was no point to offering mock features to our users that did not exist, because we would not be reducing any hits on the database. In fact, the extra work to process batch loads was taking work away from the client-side and placing it on the sever side, which felt counter-intuitive.

It made more sense to have our vendors build the logic for multiple ticket creations themselves by collecting data and making multiple individual calls to our web service methods. I believe only one of them makes asychronous calls... the rest are happy with sychronous.

baultista
I don't think it would hurt to have a createRecordBatch, because at some point your database may support it and you have already provided the interface to customers, that way, you can simply adjust the implementation of your createRecordBatch from using a "for" loop to using the database bulk insert syntax.
Nate Bross
@Nate Bross I see your point but I think I clearly hold the position now that a requirement like this should only exist if performance goals aren't met in testing
Eugarps
@Nate Bross You make a very good point... I had to take a good 10 minutes to try and remember why we ruled that option (a very good one at that) out. There was no guarantee that the way we would have designed the method(s) (parameters, datatypes) would be congruent with the core implementation. We were middleware, and the core system is a black box to us.
baultista