Teoretisk design

1. ulempe mere: det fylder i RAM.

Men du kan egentlig kun selv finde svaret, for det er kun dig der ved om du kan tåle at have en cache, eller om du kan tåle at slå op i databasen hver gang. Det afhænger af din problemstilling.  ;)

Mener du ens egne RAM eller serverens RAM?
Men jeg venter lige lidt med at beslutte mig, til jeg får lidt flere inputs.

Jeg ville anbefale en løsning hvor du konfigurativt og/eller programmatisk kan ændre den slags.
Det er jo afhængigt af hvordan dine brugere ender med at bruge dit site der har betydning for hvad der vil virke bedst.
Bruger du version 2.0 eller 1.1?
Mvh

(Som udgangspunkt får du WeakReferences hvis du benytter Cache i ASP.NET, hvilket medfører at de kan blive nedlagt, såfremt du løber tør for ressourcer)

Jeg sidder desværre stadig med 1.1 - jeg er lidt bange for at migrere til 2.0 :o)

Man lad mig smide endnu et kort på bordet:
Der vil MAX være 100 brugere på, på samme tid. Hver bruger vil MAX have 1.000 objekter til håndtering på samme tid.

Det skal du ikke være bange for .... Du kan endda hente opgraderinger så kompileringsmodel mv. svarer til det du er vant til - sig til hvis du vil have links.
De yderligere oplysninger hjælper ikke så meget - hvis de 1000 objekter strings med samme indhold - ender du med kun at have ét objekt pr. bruger... Hvis det er 5MB's billeder ser verden helt anderledes ud.
Hvad er det for objekter du kan have 1000 af for én bruger?
Mvh

Jamen, hvis det ikke ændrer på de metoder osv. jeg bruger i 1.1 - så skal jeg da se at få hentet 2.0 opdateringen.

Objekterne består af:
Små int's (7 stk.)
Små strenge (10 stk.)
Små ArrayLists (4 stk.)
DateTime's (1 stk.)
Bool's (2 stk.)

Så det er ikke det vilde vi er ude i.

Som det nok også fremgår af ovenstående, så er det 1.000 objekter der stammer fra samme klasse.

2.0 Installeres så det kører side om side med 1.1 - Så fordi du installerer 2.0 medfører det ikke at dine gamle apps kører 2.0 (men det kan du self. få dem til).
Du kan også hente gratis værktøjer at udvikle applikationerne (hvis du ikke har noget VS licens væsen i forvejen).

Du kan benytte en profiler til at finde ud hvilket impact din løsning har på memory etc. på kørselstidpunktet... Der findes en gratis her:
http://www.microsoft.com/downloads/details.aspx?FamilyID=a362781c-3870-43be-8926-862b40aa0cd0&DisplayLang=en

Og den findes self. også til 1.1:
http://www.microsoft.com/downloads/details.aspx?familyid=86CE6052-D7F4-4AEB-9B7A-94635BEEBDDA&displaylang=en

Men som sagt... Hvis du benytter Cache (eller en kombination af cache og egen logik) kan du lave en løsning der er fleksibel mht. hvorvidt objekter caches, eller hentes ved hvert request.
Hvis du benytter en OR-mapper vil det typisk også være faciliteter du har til rådighed.

Mvh

Jeg vælger nok at benytte mig af løsning 2 - Så er der ikke andet for end at se hvordan det performer, og hvis det er helt galt, må jeg optimere koden til den tid - og lader derfor døren stå åben for løsning 1.

Men jeg lukker dog ikke tråden endnu - jeg vil meget gerne have flere meninger til dette problem.

Ellers laver jeg en blanding - hvor objekterne bliver gemt i en session, og når så der skal bruges kritiske oplysninger fra disse objekter, bliver de opdateret med det nyeste indhold fra databasen. Hvordan lyder det?

Men så kommer der et spørgsmål:
Kan en session håndtere 1.000 af disse objekter, uden at tabe data?
Jeg er sådan generelt meget skeptisk når det gælder sessions.

Nu kan du jo arbejde med session-data på flere måder.
Pr. default bliver session data gemt in-process, hvilket giver den bedste performance, men den ringeste stabilitet - f.eks. vil en genstart af applikationen medføre tab af sessiondata.
Du kan også sætte en stateserver op, hvilket medfører at du taber sessiondata hvis denne server rebooter.
Slutteligt kan du gemme dine sessiondata på en sql-server, hvilket så må betragtes som den mest stabile løsning - men altså ikke det hurtigste.
Der er lidt issues omkring sessions og outputcaching der kan skabe lidt ballade i visse situationer.
Hvis du ender med at benytte 2.0 - har du mulighed for at benytte profiles, hvilket også sikrer persistering i en database.... Det er lidt afhængigt af hvad det er du gemmer hvorvidt det kan være relevant at kigge på det.
Mvh

er det forskellige 1000 objekter per bruger ?

hvis ikke så ville du nok spare en del memory ved at gemme dem fælles (application scope)
fremfor per bruger (session scope)

du kan lave en simpel test som viser dig hvor meget dine objekter fylder, så kan
du regne lidt på om du har plads til 100 x 1000 af dem

generelt synes jeg at du skal starte med at hente dem fra databasen, når
de skal bruges og ikke før

så måler du performance på det og hvis ikke den er tilfredsstillende, så
implementerer du en cache løsning

med stor sandsynlighed er den indbyggede cache bedre end hvad du selv kan strikke
sammen

reliability af cache er ikke kritisk fordi logikken er jo at smutter den, så starter
man bare forfra med at hente fra databasen

opdateringer skal selvfølgelig gennem cachen

hvis din lag struktur er lavet fornuftigt så bør det ikke kræve store
ændringer at implementere brug af cache

Hej Arne,

Hvad mener du med om de er forskellige? Altså, de stammer fra samme klasse - men de indeholder jo ikke ens data.

Men jeg vælger at bruge den løsning jeg fandt frem til i min kommentar:
11/07-2006 13:13:15

Så hvis alle de implicerede vil smide et svar, så deler jeg point ud :o)

forskellig som i at den Equals metode du har implementeret for klassen returnerer false
fordi de har forskellig id eller forskelligt navn

selv ved kun delvist overlap kan der være fordele ved en fælles cache

musicchart>

Tid at få afsluttet her ?

Hej Arne,

Ja, jeg venter stadig på svar, efter opfordring i min kommentar 12/07-2006 09:55:46

Jeg samler ikke på point, tak.

jeg er lidt i tvivl om hvorvodt jeg er inklusive, men  her er et svar fra mig

Yes, snepnet >> vil du være med ? :o)

Ok :o)
Mvh