What is the life cycle of a standard dynpro application?

[Former Member]

Hello,

What is the life cycle of a standard dynpro application?

When a standard Web Dynpro application is running what is hapenning "behind the scenes" when few users are starting the application from the portal? Does the WAS creates a different instance of the view for each client request or spawns a new thread? And what happen with the controller? Is it shared by all users?

[Former Member · Accepted solution]

Roy,

<i>Does the WAS creates a different instance of the view for each client request or <u>spawns a new thread</u></i>

SAP WebAS (as any J2EE server) has a pool of threads. With every user request thread is grabbed from pool, request is handled within this thread, and thread is released back to pool afterward. How server manages pool? Well, it can pre-create all pooled threads on start, pre-create set of threads on start and create new ones if necessary (expand pool) or remove unnecessary ones (shrink pool) during life time. So policy may be different. In any way, it is highly optimized and does not mimic "create thread / destroy thread per-request" policy

<i><u>And what happen with the controller? Is it shared by all users?</u></i>

No! Every controller life time is same or shorter then life time of WD application. So it is even more "narrow" scope the per-user one, while user may run several WD applications simultaneously.

Valery Silaev

EPAM Systems

http://www.NetWeaverTeam.com

[Former Member · Accepted solution]

Hello Valery,

Thank you for the quick and efficient response (as usual).

Few questions arose now:

1. So each client request creates new Controller?

2. Does it mean that every instance member I declare inside a view is not thread safe?

2. Why can't I declare a method as synchronized when I use the wizard to create new method and I can do that only at the "unprotected area at the bottom?

Message was edited by: Roy Cohen

[Former Member · Accepted solution]

Roy,

<i>Thank you for the quick and <u>efficient</u> response (as usual).</i>

Actually, response was not so <i>efficient</i>, according to your following questions

<i> So each client request creates new Controller</i>

No. When controller life cycle is managed by WD, then controller is created on demand (on first use) and stay alive as long, as application is alive (interface controller, component controller, custom controller, component usages, view controller). Optionally, you may declaratively make view controller to stay alive only when view is visible. On other hand, if you create/destroy component usages manually, then all related controllers of embedded component (interface controller, component controller, and custom/view controllers that have been already incarnated on demand) can be destroyed earlier then application ends.

<i>Does it mean that every instance member I declare inside a view is not thread safe?</i>

This means exactly the opposite

Threading model of WebDynpro (and other types of J2EE applications) allows you to write thread-safe code without explicit multi-threading synchronization.

Your instance members of WD controllers at any given moment of time is accessed only by one thread. So no synchronization is necessary.

Sure, you can add mutable static fields or pass some reference to non-thread safe code, and, hence broke built-in thread-safety pattern of WD. But any language/tool/framework provides enough rope to hang oneself

<i>Why can't I declare a method as synchronized when I use the wizard to create new method...</i>

See above: as far as controllers' variables are accessed from single thread there is no case for explicit synchronization.

Valery Silaev

EPAM Systems

http://www.NetWeaverTeam.com

[Former Member · Accepted solution]

Valery,

First, the fact that I didn't understand does not mean that your answeres are not efficient. On the contrary my friend...

I am still confused though regarding answer 2.

By default J2EE applications are multi threaded. Only if your Servlet implements the SingleThreadModel than you are thread safe and the situation you described is true. But I don't see where the DynPro implements this interface...

And regarding the synchronized:

So if I understand correctly, there is no room for synchronized ever in a DynPro application. Correct?

[Former Member · Accepted solution]

Roy,

<i>By default J2EE applications are multi threaded. Only if your Servlet implements the SingleThreadModel than you are thread safe and the situation you described is true. But I don't see where the DynPro implements this interface...</i>

This is true for servlets. Because the very same servlet instance is used <b>simultaneously</b> to handle several requests.

However, WD application (and all nested components/controllers) is accessed only by one thread at any given moment of time. If same application type is running under several users, every user has own application instance. So there is no simultaneous multi-thread access to one instance. Hence no need for explicit synchronization.

Btw, there is no need to synchronize methods in EJB (neither entity, nor session). Mechanism here is a bit different, thoughts.

<i>And regarding the synchronized:

So if I understand correctly, there is no room for synchronized ever in a DynPro application. Correct?</i>

In 99.9999% -- yes. Yes, if you don't use well-known anti-pattern of passing data to wdDoModifyView via mutable static variable, and you do not pass WD context or mutable controller instance variables to your custom non-thread-safe code (very esoteric case, btw).

Valery Silaev

EPAM Systems

http://www.NetWeaverTeam.com

[Former Member · Accepted solution]

Valery,

<i>If same application type is running under several users, every user has own application instance.</i>

Again I'm confused: First we say that for every user request for the application <b>new thread</b> is created now we say that every user <b>has it's own application instance</b>... What am I missing here?

When you say new application is created what does it include? all the Controllers/Components/Views/Interfaces I defined at my project? And if so, I don't see the efficiency in it...

[Former Member · Accepted solution]

Roy,

1. Application is created once, when it is accessed for first time by user (i.e. application session starts)

2. Application has state. This is conext + instance variables of all components / controllers involved.

3. Application has behavior (sum of all methods of application's compoents/controllers). This behavior is executed on user interaction (triggering some action on UI), HTTP reuest must be performed to handle such action.

4. HTTP request is "executed" on some thread (allocated from thread pool).

5. When performing request, some application's methods are executed, these methods access/modifies application's state.

6. <b>However, during processing request one and only one thread (thread, that handles request) may access/modify application state. </b>

Key point here: application state is accessed only by one thread at any given point of time. Any read/write of instance variables originates from one thread that "runs" request. There is no need for synchronization in this case.

<i>When you say new application is created what does it include? all the Controllers/Components/Views/Interfaces I defined at my project? And if so, I don't see the efficiency in it... </i>

WD has laizy loading policy for all controllers. So when you create application, the following will be created:

1. Component controller of top-level component.

2. Interface controller of top-level component.

3. Interface view controller of top-level component.

4. Any view controller of visible views that are included in interface view window (corresponding to interface view in [3])

5. Any custom controller / controllers of embeded components if and only if you "touch" them via...

a) method invocation;

b) context mapping + context node element access;

c) embedding interface view to visible window of top-level component;

...from wdDoInit method or start-up plugs of controllers listed above. Hence, if you not touch them, they will not be created.

Valery Silaev

EPAM Systems

http://www.NetWeaverTeam.com

[Former Member · Accepted solution]

10X again for the effort and the clear explanation

[Former Member · Accepted solution]

Hi Roy,

have you read this?

http://help.sap.com/saphelp_nw2004s/helpdata/en/d2/8acd409cc4dd50e10000000a1550b0/frameset.htm

http://help.sap.com/saphelp_nw2004s/helpdata/en/13/aeeb41eda96624e10000000a1550b0/frameset.htm

Regards, Heidi

[Former Member · Accepted solution]

No I haven't but I definitely will! 10X