[iPlanet-JATO] Re: question on JATO
Hi Syam--
> Your assumption is correct. My application is storing in
> NDUserSession.
Cool.
> Actually I thought of doing this in the following way to avoid
> caching.Extend a class from DataSetModelExecutionContext, which will
> have the extra attribute of type Keys.
>
> This Object will be passed in as a parameter to Model's retrieve()
> method.The retrieve method() will use the passed in Keys(received
> through passed in Context) in the Mainframe Call. Before returning
> from the call, it will Modify the Context object with the Keys to be
> used in the Next call. ViewBean will store this context object as a
> pagesession object and will retrieve in case of NextSet request.
This is essentially what I was going to suggest after you described how the
MQ data retrieval works. This is exactly the kind of behavior and extension
the execution contexts are intended to support. I'm glad that came through,
since I don't think we explained it at all! It seems that all that is
required is that the MQ message limit be the same as the maxDisplay limit
for the tiled view displaying the data, and your Key objects should line up
with the display.
As for doing First, it seems that you could just ignore using an existing
key, and the server would return data from the beginning of the result set.
Last is a bit more difficult, in that you seem to suffer from the same
problem we have in JDBC: you don't know the ultimate result set size
beforehand, so you have to retrieve all the data and then back up X number
of rows. The problem even with this is that you may not have a way to
retreive a Key object that can be used for backward navigation.
In fact, isn't this a problem with backward navigation in general? How are
you planning on getting around this for the Prev button? Would you need to
store the list of keys you used to iterate forward?
> I am assuming this approach works fine for Next and Previous with
> extra overhead of making MQCalls in every request. When it comes to
> Last/First it fails.
In general, I would think the incremental MQ calls would be far more
efficient. For instance, in the scenario you outlined in your prior
message, you'd always retrieve all of the result set, making a calls to MQ
for each portion of the result set. Instead, with this new technique, you
would spread out the calls to MQ over several requests, and wouldn't need to
retrieve the full result set if someone found the data they're looking for
before the end of the data. So, I would say the new technique is far less
overhead.
Todd
