Marshalled

huh?

jeg tænkte det samme <<redfox

Hvordan har du fået et scripting.dictionary til at ligge i en application variabel?

tjaa <<nlunn det er en hemlighed ....
.
.
.
ok sådan her
<OBJECT RUNAT=Server SCOPE=Application ID=varObj PROGID="Scripting.Dictionary"></object>
i global.asa

og så sådan her
Application.lock
    set Application(session("room") & "users") = varObj
Application.unlock

takker ;)

Jeg har bare ikke selv kunne få det til at virke tidligere.

Såvidt jeg ved kan man ikke ligge objecter i application-variabler

kan du ikke lave det med et array istedet?

Du laver simpelthen den mest grundlæggende fejl af alle hvis du ligger dictionary objektet i en applikations variabel. Den er Aparment-threaded. Det vil sige at alle kald skal marshalles ind i den aparment dit objekt ligger og bliver der lagt i messag pumpen for objektet, hvilket betyder utrolig dårlig skalering og stor stor risiko for deadlocks.

Det giver dig også den fejl du modtager, hvilket betyder at objektet er låst af IIS indtil marshaling er færdiggjort og vendt tilbage, så den nuværende tråd kan komme til. Dette kan muligvis undgås, men du kan ikke undgå låsninger og rigtig dårlig skalering.

Efterhånden er det jo egentlig også standard viden at *ingen* objekter skal ligge i hverken session eller applikationsobjekter, hvis du ligger dem i session variable bliver de betragtet som enkelt-trådet objekter, hvilket er meget dårligt. Hvis du ligge dem i Applikations variable skal de MTA objekter (det er Dictionary ikke) og skal beksyttes ved enhver tilgang med låsninger, hvilket effektivt også låser alle andre tråd adgange.

<<s nej for informationen i den skal være tilgængelig for alle på sitet

<<skovlunde alt det der skal nok passe, men det står altsår i en bog skrevet af en der skulle have en del forstand på ASP

Du kan sagtens ligge en array i en application-variabel som så er tilgængelig for alle.
Jeg vil holde med skovlunde i at det er en meget dårlig ide med at ligge et dictionaryobject i en application-variabel.

Har du tænkt på at ligge dataerne i en tabel i en database hvor du så kan tilføje og slette brugere?

det skal bruges til at holde styr på bruge i et chat room
jeg har fundet problemmet. Det var PWS der ikke kunne finde ud af det, for på IIS 4 og 5 virker det fint.

reason>> Ja, der står meget lort i mange bøger, især fra de billige forlag som Wrox, Sams osv... Som regel er de skrevet af folk der kan deres ASP til fingerspidserne, men mangler viden om COM, som er essentielt for forståelse af IIS og ASP fortolkeren. Tjek der link hvis du ikke tror mig:

http://msdn.microsoft.com/workshop/management/planning/MSDNchronicles2.asp

Du kan ikke lave noget seriøst i ASP hvis du ikke kan din COM - det er fakta!

skriv en bog

forresten har jeg fundet et citat til dig skovlunde :
Store commonly requested, unchanging content in memory using an application-scope Dictionary object.

det er taget her fra :
http://msdn.microsoft.com/library/sdkdoc/bdg/bdgapp03_3rhv.htm

Tjaaa hvis du vil være en spasser så put dog dit kære Dictionary objekt i Application variablen. Men du har jo tydelig vis ikke læst det link jeg viste, som jo faktisk forklarer hvorfor man har forslået netop det optimering tip du lige har vist. Men OK hvis du er for lam til at forstå det, så er jeg sikker på at dit hosting folk vil være glade når din ASP application ligger serveren ned så snart der bare kommer over tyve besøgende på en time.

du sagde
Du laver simpelthen den mest grundlæggende fejl af alle hvis du ligger dictionary objektet i en applikations variabel.

er det her ikke det modsatte
Store commonly requested, unchanging content in memory using an application-scope Dictionary object.

eller er det dig der er lam?

Læs dog det link jeg har posted!...Fatter du intet. At ligge et markeret MTA komponent, som kun er Apartment threaded, i en Applikations variabel er en dødssynd.
Men du forstår jo tydeligvis ikke hvad det handler om. Læs det link jeg posted - hvis du ikke fatter det, hvilket du nok ikke gør, er det bare ærgeligt og så lig dog dit data i dictionary objektet hvis du synes om, at blindt følge alt hvad du læser, uden at forstå hvorfor.

dvs at du mener det her er en dødssynd
Store commonly requested, unchanging content in memory using an application-scope Dictionary object.
selv om det er skrevet af microsoft folk?

(og jeg læst linket)

Du bliver ved...Du har ikke læst mit link som netop fortæller dig at Dictionary objektet har fejlagtigt være anset for et MTA komponent. Det er skrevet af MSDN holdet, som har en god del styr på det de laver.

Så lad mig spørge dig om noget andet: Hvornår er det information du klynger dig til fra? Er det ASP 1 eller ASP 2. Hvilken IIS version? Hvilken service pack?


Endvidere bare fordi MS skriver noget er det bestemt ikke ensbetydende med at det er sandheden, og hvis du tror det har du alvorlige problemer. Men OK, så læs dette:

The original Dictionary object developed by the scripting team was apartment-threaded, because the team assumed that everybody would use the object on the client side -- and the extra effort to make it both-threaded wouldn't be justified. As it turns out, everybody wanted to use it on the server.

Even that wouldn't have been a problem if the Dictionary object call was limited to page scope on the server (it's unlikely that the object would be called more than once or twice from a single page). But if the Dictionary object call were set to session or,

Læs det næste nøje:

heaven forbid, application scope, the number of requests it could be forced to process would mushroom -- and with it, the probability that server speed would bog down.

To make matters worse, there was a hiccup in the installation process. Even though the Dictionary object was apartment-threaded, the installation process set the host computer's Registry key as if the object were both-threaded. The ASP team was excited to see a both-threaded Dictionary object appear, and encouraged folks to use it on the server in application scope to reap all the benefits of hashes. Whoops.

So what happens when an apartment-threaded object is treated by ASP as if it were both-threaded? At some point -- usually when two threads modify the same piece of data without being aware of each other's actions -- a piece of data on the server is corrupted or set to a value the Web application isn't designed to handle. Some time later, the server tries to access the data -- and boom, server crash. The likelihood of this happening increases with the traffic the server faces, so the server tends to crash at the times when you will aggravate the most people possible.

Hardly the ideal choice for Web developers: a slow object or a crash-prone object.


Hvis du ikke er overbevist nu, så glem det.

jeg har læst dit link men tak for citatet  ; b

jeg tro skam ikke på alt hvad microsoft siger, men lige ved jeg ikke hvad jeg skal tro, for jeg har fundet flere aktikler (på msdn) som er nyere end dit link hvor der står at der ikke er nogle problemmer med at ligge en Dictionary i en application variabel.

så det skulle være du skulle læse noget mere før du begynder at komme så arrogante udtalelser

Tro hvad du vil. Du har ikke fundet nogen nyere link om dette end det jeg gav. Det er lige meget jeg kan gennemskue teknologien, det kan du tydeligvis ikke.

Kan vi få kammertonen tilbage?
Tak!
Skovlunde - du lyder som om du har styr på det, men hvad med den mere robuste dictionary objekt: LookupTable?
(som stod kort beskrevet i artiklen som du linkede til. Siden er gået ned, så jeg kan ikke læse mere om det).

Kammertone? Hvad mener du? Bare lidt fjendtlig mobberi er jo altid velkommen i en ellers så trist hverdag...:)

Jo LookUpTable er alternativet til Dictionary objektet. Der findes ligeledes også en del andre objekter som har samme funktion - og som det kan anbefales at bruge...

Den kan downloades her:

http://msdn.microsoft.com/workshop/server/downloads/lkuptbl.asp

Nu hvor jeg ikke må bruge dictionary hvad kan jeg så bruge? (ikke lookuptable)

Du kunne jo bruge en array :-)

ja - men det er monster besværligt

Men det virker...