Are you seriously talking about a _single transaction_ taking 6 - 8 _hours_ ?? That is going to cause a _whole lot_ of problems. And I find it pretty hard to believe that what you have here is an OLTP process of some kind. What is the message? What is the processing associated with it?
Basically, what are you trying to _do_ ? As an aside, please note that there is a difference between the notion of a message in RSB terms and the network utilization involved. Using Rhino Queues, for example, we will bundle multiple messages into a single round trip to the remote server, not make a single call per message. On Sat, Jun 18, 2011 at 9:17 PM, René M. A <[email protected]>wrote: > We are also concerned with the other stuff involved, e.g. saving the > request so that it can be correlated with the results at a later time, > validating the request in terms of whether the specific commands make sense > for the hardware units requested etc. > This is expensive for the large requests, but those requests (often with > thousands of ids) is usually only carried out once a day and often during > the night. It is acceptable that this request takes hours to complete (worst > case up to 6-8 hours, most of the time spend in the network). The priority > here is that the radio network, is utilized efficiently, because if not, the > request will take more than the night to complete. > > During the day several smaller request will be made against more specific > hardware ids. These request can contain between 1-500 ids and again the > network is the primary bottleneck. > > I understand your concern regarding unbounded result sets, and hopefully we > will be able to design it differently in the future, as the hardware get > smarter and better but for now I can't see how we can do it much > differently, but performance is a major concern for us. So as to whether the > collection size limit of 256 items is reasonable or not, I guess it depends, > I still believe we have a valid scenario where it should be bypassed. > > -- > 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/-/J-KXC0uju4cJ. > > 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. > -- You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group. 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.
