Architectuur probleem met ASP.Net Applicatie

[baskabas]

Op de zaak zijn we bezig met een webapplicatie in ASP.NET (2003).

We maken gebruik van .Net Framework 1.1 en de Microsoft Application Blocks (Cache, Configuration, Data, Exception Management en UIProcess).

Hij maakt gebruikt van:
- Server A een state-database, SQL Server 2000, Windows 2000 Server
- Server B Webservices via .Net remoting. IIS 5.0, Windows 2000 Server

Als we de applicatie lokaal draaien op de laptop's, dan functioneerd deze prima, maar als we de applicatie op B hosten (intranet), dan komen er allerlei rare problemen opduiken zodra en meerdere gebruikers aan de gang gaan.

De problemen:
I. De applicatie lijkt op willekeurige momenten gegevens te verliezen.
II. Soms doet de navigatie iets totaal anders als normaal.

Het rare is dat de problemen sporadisch opduiken... alles wordt zorgvuldig getest en ge-hertest... daarom denk ik ook dat het eerder in de architectuur zit dan in de coding... want vanaf meerdere latop's tegelijk werkt het wel, maar vanaf 1 server ineens niet meer...

De verschillen die ik kon bedenken zijn:
I. dat de verschillende sessies van B richting de state-database (A) en de webservices (B) onder dezelfde user-account / machine draaien.
II. de website in een secured folder staat.

Iemand suggesties?

[baskabas]

We zijn al wat verder...

We hebben nu enkel nog problemen op de productie omgeving...
Daar raken we de session id kwijt... waardoor de ASP.Net state niet gevonden kan worden...

Productieomgeving
- 2 webservers (loadbalanced)
- 1 statedatabase
- Cookieless connectie (session id in url)

Het lijkt erop dat het met loadbalancing te maken heeft, want hij vind de state op den duur wel weer... (heleboel GET's in de trace informatie zonder ID)...
maar waarom via de ene server waar de sessie gestart is wel en via de ander niet?
We gebruiken toch maar 1 state database?!?

[ Voor 7% gewijzigd door baskabas op 06-09-2004 12:05 ]

[igmar]

Wordt de state database wel door beide webserver gebruikt ? Met veel LB's is het zo dat een bepaald IP altijd bij een bepaalde webserver uitkomt, maar dit is echter geen regel.

[baskabas]

Ja, natuurlijk... dit wordt gestuurd vanuit de Web.config file van de applicatie... en die zijn voor beide servers identiek...

[baskabas]

We hebben het probleem op kunnen lossen...
Het UIProcess Block van Microsoft bleek inderdaad state te verliezen, omdat deze moeite had met het serializeren van bepaalde objecten.

Oude settings:
- UIP: enableStateCache = true, statePersistenceProvider = SqlServerPersistState
- ASP: sessionSate = SqlServer

Nieuwe settings:
- UIP: enableStateCache = false, statePersistenceProvider = SessionStatePersistence
- ASP: sessionSate = SqlServer

Op deze manier gaat de de caching via de ASPState naar SQLServer in plaats van naar zijn eigen UIPState database.