Asynchronous Requests

[atuldalvi]

How can we have a Asynchronous call to same .p in loop

e.g.

Do i=1 to 5:
RUN async1.p ASYNCHRONOUS
SET hProcess
EVENT-PROCEDURE "endasync" IN THIS-PROCEDURE
ON SERVER hServer
( INPUT param1,
OUTPUT param2,
INPUT-OUTPUT param3 ).
End.

I just want to call that .p in loop and continue processing for the next record in loop. dont want to wait for the previous call response.

 

[GregTomkins]

We never use async requests, we have a whole different approach, but here are 2 thoughts:

1) Possibly hProcess should be an array indexed by 'i', so that you can track each request handle and figure out what to do in endasync;

2) Back when we contemplated using async requests, someone alleged that multiple requests on the same SERVER handle (hServer in your example) would run serially, not in parallel, on the AppServer; and that for them to run parallel, you'd need to use separate server handles. Note that this is NOT the same thing as running async with respect to the client. This might be totally false, but if I were doing this, I'd check that out.

Edit: formatting

 

[atuldalvi]

Hi,
Still finding on this. I dont want to catch response of called ASYNCHRONOUS .p. I just want to call that .p ASYNCHRONOUSlly and continue processing without waiting for that .p reposnse.

Is there any way to handle such situation ?
Or
How we can handle this situation in above mentioned code ?

If possoble, please provide code for the same.

 

[RealHeavyDude]

If you don't want to be triggered when the request is processed - then why does your request have output parameters?

I would never call the AppServer repeatedly in a loop - even more so asynchronously. You might wind up consuming all AppServer agents and thus rendering the AppServer unavailable for other requests. IMHO - something like this is bad practice.

Furthermore it is much more efficient to send a lager amount of data in one network roundtrip than sending small amounts of data in numerous network roundtrips.

You should always have performance and efficency and scalability in mind when coding against the AppServer.

Instead of repeatedly calling the AppSerer I would pick up all the necessery input, output and input-output parameters in individual temp-table records. Then send the temp-table to the AppSerer, process it in one request and hand the temp-table back to the caller.

Whatever it is you are trying to achieve - IMHO - you should re-think your design.

Heavy Regards, RealHeavyDude

 

[atuldalvi]

Not fully satisfied.

Even if i pass whole temp table i have to wait till previous record gets processed in the record set. I dont want to do that.

I want to continue processing for the next record in loop without waiting for the previous record gets processed.

Is there any solution on it ?

 

[TomBascom]

Do you imagine that the 4gl is multi- threaded?

It is not.

 

[atuldalvi]

is there any other way to to accomplish this requirement ?

 

[TomBascom]

Your requirement is either unclear, unreasonable or misguided.

 

[RealHeavyDude]

I couldn't agree more with Tom. In your post you describe something that you technically want to achieve. Usually there is a business requirement ( or should I say should be? ) behind any solution you code. To me it is totally unclear what this business requirement could be. Maybe if you shed more light on the underlying business requirement we can be more helpful.

If you are thinking about solving the lack of multi-threading support in the ABL with an AppServer - then we can tell you that you can't.

Heavy Regards, RealHeavyDude.

 

[TomBascom]

In other words...

If your requirement is that the 4gl be multi-threaded (it is unclear if that is actually what you require, but it seems to be the thrust of your inquiry) then that is unreasonable and misguided because the 4gl is NOT multi-threaded.

It is also very probably not a very good solution to the (rather unclear) problem at the root of your query. You have put forward a very generic "problem" of processing each record in a temp-table. You have not explained, at all, why there is any need to process each record asynchronously or in its own thread. Nor have you explained the nature of that processing and how it could (rather unbelievably) be more efficient to marshall the data one record at a time across an app server boundary. You have simply asserted that that is your so-called "requirement". And you have failed to answer the question of why your example includes an output parameter -- which would certainly have an impact on the workability of using asynchronous app server calls to meet your "requirement".

Fake examples of "problems" that people don't actually have generally don't result in useful responses in forums.

 

[TheMadDBA]

This really sounds like you have a performance problem that you are trying to solve and you have already decided that multi threading is the way to solve this. That is almost never the case for UI based logic, even with databases like Oracle or SQL Server that support parallel query processing or UI languages like .NET that support threads. People still implement both for a lot of issues that could be solved in much easier ways, but that doesn't make it the correct solution.

Most of the times there are tuning options to reduce the time of the calls. It is much better to fix the issue so your total request runs quickly instead of running 10 threads that are each running a poorly tuned query/procedure in an attempt to reduce the response time.

Like the others have suggested you would be best served by describing the issue you are trying to resolve and we can probably come up with quite a few ways to help you.

 

[TomBascom]

It sounds like a hypothetical question from someone that comes from some other background. Or an interview question / homework.

 

[TheMadDBA]

That is also a possibility.

This just wouldn't be the first time where multi threading was viewed as the first step in tuning application performance. Either because the 4GL programmer came from a threaded language or works with people that do.

Note that I am not saying that this mindset is correct... just very common.

 

[RealHeavyDude]

While I do a lot of Java coding I rarely use multi-threading. For one, you need to be very careful and absolutely need to know what you are doing. You don't master multi-threading just like the other coding technique / design pattern. Plus, there needs to be a compelling reason using multi-threading. Poor query or update performance on a database is not. So far I can't remember having used multi-threading when designing business logic.

So many times I see people trying to break through a towering wall instead of trying on the side where you might be able to jump over the wall.

Heavy Regards, RealHeavyDude.