My company has developed 2 win apps and 1 web app. All 3 apps use a
'common' business logic component (vb.net dll) and data access
component. We recently refactored the common components to use common
error handling and database auditing. This is done in the data access
(DA) component (layer). When a user on the web app logs in (forms
auth), their username is populated to a public property in business
logic (BL) layer. When required, BL layer calls methods in DA layer
which retrieve username from exposed, public BL property Now what I'm
seeing is DA layer methods NOT reflecting the 'real' username. It's as
if the BL public properties are being held and retrieved from
Application State. Remember that BL is used by web and windows apps, so
there is no explicit pushing and pulling of properties from application
or session state as 'state' does not exist in win apps.
When we first implemented the refactored applications, I was suprised
that they actually worked as I did NOT expect the 'shared' properties
(as in username) to be retained in web app across page posts. It did
appear to work, but I am now seeing that, in username case, the most
recenlty logged in user is the value that is returned, NOT the
'current' username. It appears that asp.net is storing BL class members
in application cache, NOT in session cache, so when my web app session
retireves BL username property, it retrieves the value from application
cache, which works correctly when only 1 user is logged on, but when
multiple sessions are active, I have a problem. So, is this how asp.net
application memory is handled? How do you get around this problem as
this is surely a common scenario?
My site is running on IIS 6.0 on windows 2003 server. I am using
default application pool and settings. Apps are built in visual studio
2003.
