No the entire processing end-to-end can take 6-8 hours worst case. It does 
not happen in a single transaction.

Here is what happens:

A client puts in a request for a job which must be executed in a low 
bandwidth network (e.g. radio), reading/writing configuration and other 
values from a list of utility meters (once a day, this list can be very 
long, thousands).
The application receiving the request saves it in order to be able to link 
the results to the original request when they arrive at a later time. The 
application sends the request as a message using RSB to a service which 
hosts a component that knows about the network and how to efficiently 
execute the request. This component is a legacy component and beyond the 
scope of our project. The service starts an async job using the legacy 
component. During job execution results from the individual meters are 
available to the service which sends these results back, using RSB to the 
application which received and saved the original request. The application 
saves these results as they arrive (results typically arrive in small 
chunks).

Whats important in relation to my original question, is that the entire 
message (or messages if split into a sequence) must be received by the 
service before the legacy component is invoked. It is way too expensive in 
terms of unefficient bandwidth usage to execute smaller parts of the request 
as separate jobs against the legacy component. 
So what I refer to as a single transaction is passing the entire message to 
the service. It does not have to be a single physical transaction as long as 
I know when all the ids of the meters involved in the request have been 
received.

I know there a several ways this can be dealt with using RSB to bypass the 
256 collection size limit in the serializer, I just felt that it was a very 
artificial limit and thats why I asked of it still made sense to maintain 
it. I am still not convinced that it is the responsibility of the serializer 
to enforce such a limit?

-- 
You received this message because you are subscribed to the Google Groups 
"Rhino Tools Dev" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/rhino-tools-dev/-/vgF0GWTBK_AJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/rhino-tools-dev?hl=en.

Reply via email to