This is kind of an anti-position to some of the use cases for the multi-threading requirement the Thomas brought up in another thread in this forum. Some of the use cases did remind me of a more urgent (in my point of view) requirement:
I'd probably be using Asynchronous Appserver requests far more often when they could actually return a ProDataset to the client. That's not supported right now. Rather than opening a new construction site with multi-threading I'd see that as completing an existing - almost completed - site first.
I could use them for gathering data for a (long running) report to the client or the use cases where the client would fetch another batch of data in the background. Right now not being able to do so is less of a pain than having to use something else than a ProDataset as an output parameter.
Any plans for that in the near future?
Unfortunately this is one of those items that slips from release to release. We recognize that it is a completion item for ProDataSets and we want to get to it. However, we don't currently have it scheduled for a release.
-Martha
One of the other problems with Async AppServer requests is that they are really only partially asynchronous. What I mean by that is that if you send 5 requests to an AppServer handle and they are asynchronous, although they get processed in the background, they still get processed synchronously. That is, request 1 has to complete before request 2 can be submitted.
One of the key reasons for submitting asynchronous requests is to have asynchronous processing of all the requests. Submit all 5 and let them come back in whatever order they complete, and if the AppServer is busy, let the broker queue handle delivering them.
I think this should at least be a setting that you can set on the server handle object.
Thus illustrating the difference between merely or pseudo asynchronous and having true multi-threading ... even if the multi-threading were to be split across sessions. One really needs them to process independently until it is time for them to come back together. This should include one thread getting started and completing 10 or 100 times while another thread completes only once.
If you're willing to make a separate connection to the appserver for each aynchronous call you want to make, you can get as many going simultaneously as your server can handle from one client-side program. You can keep track of the connections with a temp-table in the client-side program and disconnect each one in the call-back procedure when the asynchronous call for that connection is done. Or you could could leave the connections for further use if you wanted.
mopfer wrote:
If you're willing to make a separate connection to the appserver for each aynchronous call you want to make, you can get as many going simultaneously as your server can handle from one client-side program. You can keep track of the connections with a temp-table in the client-side program and disconnect each one in the call-back procedure when the asynchronous call for that connection is done. Or you could could leave the connections for further use if you wanted.
Or OpenEdge could take care of the connection pooling for you, after all, it is an *Advanced* Business Language. It could accept a setting from the AppServer Broker that told the client the maximum number of calls that could be simultaneously accepted from one client and this could be a configurable parameter by AppServer partition - now *that* would be Advanced.
One of the other problems with Async AppServer requests is that they are really only partially asynchronous.
I usually use multiple connections to the same / another AppServer broker (then I could also use difference session models) for that purpose. Not a big deal, I'd say.
Works well except for Dataset OUTPUT parameters.
Thanks for your answer, Martha (marked that as helpful - even when the result is not helpful at all) :-)
But it's always good to be able to know good what to expect and what not to expect for the next release.