The Diet Coke of Evil

Results 1 to 2 of 2

Thread: The Diet Coke of Evil

  1. #1
    Join Date
    Dec 1969

    Default The Diet Coke of Evil

    I am working on creating a com object that will need to be persistent, or "virtually" persistent, across multiple pages. The basic idea is that it has a state, and when the user clicks stuff, the state changes and needs to update the page. The states are calculated by opening and parsing some file (which file depends on which event they are looking at) that generally is not terribly big (under 10k). Once the file is openened the first time for a particular instance of the object, it won&#039t need to open that file again. However, if you instantiate another object, it will open a file and read it again.<BR><BR>Am I to understand that the most efficient way of doing this due to evilness of sessions, even given that I might only have a dozen or so people visiting the site concurrently, is to reinstantiate this object on each page, passing it some "pointer" to what the state needs to be? <BR><BR>In other words, is the 10k file repeatedly being loaded several dozen times each by a dozen or so people going to be better performancewise than a session stored object? <BR><BR>I guess the best way is to try it and see, but I&#039m looking to the people who like to proclaim session variables as evil to answer this for me. My theory is that even if 100 people are looking at 10k files concurrently and clicking really quickly to the next state, I probably won&#039t use up more than a little bit of memory on the 256mb server, and the files will get cached as long as the user is looking at the same file between state changes, and therefore it&#039s better to not use a session object. <BR><BR>If all the abstraction doesn&#039t make sense, just know that what I&#039m trying to accomplish is navigating through a text file which contains moves in a game, and when the user clicks navigation buttons, it shows the next "position" of the game. The reasons for using a com object are many, and it has already been decided upon.<BR><BR>Am I making any sense, and is my theory probably correct?

  2. #2
    Join Date
    Dec 1969

    Default RE: The Diet Coke of Evil

    Session variables are not inherently evil, they are very very powerful, and we all know what happen to power in the wrong hands or used the wrong way.<BR>Putting an object in a session variable has VERY specific drawbacks - look into them, if they don&#039t apply then go ahead. <BR>I never put anything except a variant into the session!<BR><BR>So...<BR>Create and destroy the object on every page.<BR>If you have state information, save it in a variant in the session before destroying the object, retrieve it after creating the object.<BR><BR>There is lots of material about this subject, including a recent article in VB Prog.Journal<BR>-Andrew<BR>

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts