One work process can only process one user request at a time?

[Former Member]

Hi,

Is this true that one work process can only process one user request at a time? Does this mean a login user has a dedicated work process servicing him. Or many login users interleave a work process's service? How do threads in a process used in SAP?

Rice

[Former Member · Accepted solution]

Hello,

Yes, one process can only process one user request at a time.

But, the user request is a dialog step (one sapgui interaction).

After the dialolog step is processed the user context is rolled out, and the dispatcher process can give the work process to an other dialog step from an other user.

It is therefore possible to have a well tuned and responsive system with much less dialog work processes than concurrent users.

Only when a user consumes too much memory and allocates memory from the heap, then the process becomes "private" and dedicated for this user context.

This is a situation that should be avoided as much as possible...

Regards,

Olivier

[former_member184548]

Hi Rice

The question you have asked has two aspects:

1. For Dialog WP :

One user can uses one DIA WP at a time but the process is not dedicated to him. As a transaction consist of several steps : when one transaction step completed the WP is assigned to another user.This process is called as Dialog workprocess multiplexing.

Its done by using mechanisim Roll out and Roll In.

But at certain time when the process goes into PRIV mode ie it crosses rdisp/abap_heaplimit_dia. Then the WP becomes dedicated to that user.

2. In case of background WP , these are dedicated to the job assigned to it through out its execution.

Let me know if you are not clear

[Former Member]

Hi all,

Why does the whole mechanism is based on process, instead of thread? Is it because of security? Or just such design was defined before threads are well used in server implementation. In a J2EE web application (I do not just referr to sap WAS), a thread is multiplexing http requests.

Rice

[Former Member]

Hi,

I think you are right about the timing reason.

R/3 was born in 1992.

When you see the ICM modern add-on to the basis kernel, it is based on threads and no more on processes.

So, on the ABAP stack, a thread is also multiplexing http requests.

Olivier

[Former Member]

Hi,

Yes it's true. But the synchronization is such that when the user1 is not using that dialog process, it is being freed and some user makes use of it, i mean another task is taken up by that work process. This switching is done very efficiently and if the load is not too much, one can't even make it out.

But at any distinct moment which can drill down to nano seconds also at times it takes up only one task.

Regards and do reward with good points.