ADF BC AM Class Variables - Why To Avoid Them

ADF BC AM class variables - not harmful thing from the first sight. Only until we remember how AM pooling works, keep in mind - AM instance can be reused by different users through AM pool. AM instance object will keep initialized AM class variables from one user to another. This means private data of one user, will be visible to another user. This is not a bug, it just bad development practice to use class variables inside AM instance, when pooling is enabled.

Here is simple diagram, it will help you to understand described use case for sample application - SecurityFormLogin_v3.zip:

Sample application contains AM implementation class:

This class declares private variable - userName of String type:

There is pretty simple custom method, it accepts current user name as parameter and is initializing private variable (if not null). This is important - if not null, means if local variable was already initialized - it will not assign new value. If variable value will be stored inside AM instance object for different users - it will not be null for another user, who will reuse same AM instance. Method returns variable value:

This method is exposed through Client Interface:

Method is invoked from Page Definition, current logged user name is passed as argument:

Let's test it now. Login as first user - redsam:

AM variable was initialized correctly, it shows redsam as user name:

ADF Logger report correct value:

Now logout and login as scott, available AM instance is not destroyed yet and it will be reused from previous user - redsam:

And what we see - after login, still redsam is returned as user name from AM variable. This means AM variable was not null and it was not reinitialized - same AM instance object was used by two different users:

ADF logger reports the same:

If we wait some time, AM instance timeout happens and AM variable will be reinitialized for newly created AM instance - user scott is assigned: