asynchronous with single queue

R

Rutger

New Member
Hello,

I've got a question about running with an asynchronous appserver.
What I want is to do is the following:
AppServer srv-a runs procedure proc-a.
This procedure run a for each no-lock query on a certain table.
Within this query I want to start a program on appserver srv-b.
This program has to be started asynchronous and has to be put in a queue.
The asynchronous AppServer broker for srv-b has to distrubite the queue over multiple servers. Like in a session free state.

This way, I can process whatever I want to process paralel which should improve the performance of this proces.

Has anyone ever done something like this? I really want to know what problems you've encountered and how you solved this. Currently I am having problems with memory violations and the event-procedure not being triggered.

I hope someone can advise me about working this way.

Regards,

Rutger Olthuis,
Ordina OFS
Rutger.Olthuis@ordina.nl
 
What you are trying to do sounds interesting, but I am sceptical as to how much you will be able to achieve via 'parallel processing' in single-threaded Progress.

I had a look at the Asynch Appserver stuff myself a year or so ago, but never had time to pursue it.

I did come across this nice presentation on the subject by Laura Stern, maybe it will help.

http://www.techsmiths.com/wapug/Exc...nchronous appserver requests from the 4gl.ppt

http://tinyurl.com/glldq

If you get anywhere with your investigation, please post your results, as I would be interested to know exactly what can be achieved.
 
its very possible to split a job over multiple sessions using a session that
manages the job and a state-free appserver

but for one theres no shared resources so theres the added overhead
of copying temp-tables back and forth.

and what ever architecture you put together has to be practical.
simplicty is too underated.


for example one scenario where itd be suitable is managing parallel
dump and load jobs.

but with reports, for example, there are lots of data that has to be
copied back and forth.


heres a few things that can be done in parallel and even spread over
multiple machines.

a client can initiate multiple jobs running in parallel on a state-free appserver
and continue working on the client.

an application can be partitioned into diff services running on diff machines
possibly diff databases.
 
theres no way around it at some point progress is going to have to face
that multi-threading support is needed.

with processors going into dual cores and 4 and 8 cores next it will
probably be the next big buzz word.

how about us guys put together a betting pool when that will be
and put it in a savings account.

the interest alone would be crazy.


on a relevant subject when the f uck are they going to add native
timing events support
 
joey.jeremiah said:
will
probably be the next big buzz word.

how about us guys put together a betting pool when that will be
and put it in a savings account.

the interest alone would be crazy.

on a relevant subject when the f uck are they going to add native
timing events support
Click to expand...

I think you should offer these few lines to Dr. Mercer-Hush to be included in his use case.

I'm sure it would definitely swing it.:)
 
the betting part ? :)

i think, i should leave it to the professionals


my impression from other cases like the dynamic char browse is that it will
only give you a heart attack.

and besides learning a diff language will be easier.
 
You must log in or register to reply here.
Back
Top