Applications & Such

Page 1 of 7 123 ... LastLast
Results 1 to 10 of 65

Thread: Applications & Such

  1. #1
    Jason Scherbel Guest

    Default Applications & Such

    I have a question related to web applications inside a framework.<BR><BR>I am developing a framework that does some user validation and basic menuing for a number of other applications on either the same web server or others.<BR><BR>In the framework application, I&#039;ll get the username and some other "global" style variables that all of the children applications will need.<BR><BR>What is the BEST way to get these items to the other applications? If all applications were on the same web server, does that make a difference?<BR><BR>Thanks for your time...

  2. #2
    Join Date
    Dec 1969
    Posts
    96,118

    Default RE: Applications & Such

    Well, you can NOT pass either Application or Session values from one application (virtual directory) to another, so I&#039;m not sure there is *ANY* "good" way, let alone any "best" way.<BR><BR>I guess it comes down to cookies or hidden form fields. And that&#039;s about the only choices. <BR><BR>Files? Fine...how do you know *which* file? (hide the name in a cookie? ummm...didn&#039;t I suggest cookies?)...<BR><BR>Temp database tables? Fine...how do you know the record id that applies to this user? (hide it in a cookie...no let&#039;s not go through that again)<BR><BR>&#060;SHRUG&#062;Choose one of the two.&#060;/SHRUG&#062;<BR><BR>Neither is really secure, as you know, but you could always encrypt the info, if you wanted. Since you don&#039;t have to publish any public key, since you can keep all the encoding methodology 100% hidden, even a relatively simple algorithm will make the data pretty secure.<BR><BR>(Of course, the easy solution is to *NOT* have *separate* applications...just use one big application--with only one global.asa--and just designate subdirs as subapplications.)<BR><BR>

  3. #3
    Join Date
    Dec 1969
    Posts
    159

    Default RE: Applications & Such

    Don&#039;t use sessions, one of the top guys in industry gave me that advice.

  4. #4
    Join Date
    Dec 1969
    Posts
    96,118

    Default Bull***t

    Sorry, but I hear "don&#039;t use sessions" so much I want to scream.<BR><BR>That wisdom comes from MS. And from Charles Carroll. And others.<BR><BR>With never any "qualifications."<BR><BR>That is, they never put in the "IF" part...<BR><BR>Don&#039;t use session *IF*:<BR><BR>(1) You have a *very* busy site. Tens of thousands of visitors per hour or more. Or...<BR>(2) You need to store a *lot* of information per user someplace.<BR><BR>But since something like 95% of ASP sites are neither busy (my "Newbie" site has had maybe 10,000 hits in a year) nor do they need to store more than a few bytes of info per user...well, the advice is pretty bogus on such sites.<BR><BR>Look...consider this:<BR><BR>Suppose you store the user&#039;s login id and email address and a few other chunks of info in the session variables. Total, maybe 200 characters of info, okay? With system overhead and the fact that a character takes 2 bytes in VBS and COM, let&#039;s be conservative and say each *concurrent* user needs half a kilobyte of memory for the session info.<BR><BR>Now, suppose you get 2000 visitors an hour who stick around for an average of 10 minutes each. Add to the 10 minutes another 20 minutes for the session to time out (the default), and that means you need each visitor&#039;s session values to stick around 30 minutes. So at 2000 visitors per hour, on average you need 1000 sets of session values.<BR><BR>Times 512 bytes.<BR><BR>Total memory needed: 512,000 bytes!<BR><BR>HALF A CRUDDY MEGABYTE!!!<BR><BR>At today&#039;s memory prices, that is about 35 CENTS of memory!!!<BR><BR>I will happily *SEND* you the 35 cents just to keep you from writing the extra tens or hundreds of lines of code you will need if you avoid session variable values.<BR><BR>SO...<BR><BR>DO THE MATH!<BR><BR>Analyze YOUR situation. Don&#039;t take any pundit&#039;s word for it (certainly not mine! do your own math!). And *then* decide what makes sense TO YOU.<BR><BR>


  5. #5
    Heaven's Martini Guest

    Default Just to reiterate

    Rock on Bill.<BR><BR>That is such a huge misconception.<BR><BR>As you mention "Use them wisely" <BR>not "Don&#039;t use them"<BR><BR>I am near sick of hearing it too, and I have only been around for 11 months. &#060;shrug&#062;

  6. #6
    RDM Guest

    Default Web Farms...

    This is all very true. Sometimes people take advice and try to apply it to all situations. If there is ever a chance that the web site might eventually grow into a web farm (even a small one), then session variables do complicate matters some. Otherwise, the performance concerns raised aren&#039;t always valid as you have so elequently stated...Every development situation is different and should be handled accordingly...

  7. #7
    Join Date
    Dec 1969
    Posts
    96,118

    Default But solutions are coming...

    ...even for Web farms. Consider a *separate* machine whose only task is to manage all the Session values. Perhaps by making Sessions be DCOM objects or perhaps using some more efficient mechanism. <BR><BR>Anyway...<BR><BR>*HOW* is that any different than using a database to save the session info? Heck, it could even be implemented by using a high performance DB engine that has a gigabyte or more of memory for caching and buffering. <BR><BR>But now the *coding* of the ASP page is dead simple--just us Session values and be oblivious to what is happening under the covers--and yet you have the same scalability as any DB based solution (maybe more, since the session DB could be on a different server than the one the ASP pages connect to when they do "real" db work)!!!<BR><BR>So... today&#039;s answers are not always the final ones!<BR><BR>Remember, a lot of the strictures against session values were "invented" by MS and Charles perhaps 3 years ago, when a *large* machine had 64MB of memory. Today...can you even *buy* a server with that little???<BR><BR>

  8. #8
    Join Date
    Dec 1969
    Location
    Los Angeles, CA
    Posts
    21,192

    Default We already have solutions

    I have always been one to suport sessions espically when they make things easier. Obviously with thounds of hits a day it will make a differance but IMO when you do it wrong., like save a session object. Let us say you only have the userId in the session variable what is your problem?? Memory does not really cost an arm and leg<BR><BR>but why make things difficult when you can more or less do similar things using cookies or whatever..yes. But to arbitarly say "DO NOT use session variables"...i can only say "little" knowlede is a dangerous thing.<BR><BR>I read a small article on using session in a web farm...let me see if i can find it<BR><BR>this was one of them<BR>http://msdn.microsoft.com/workshop/server/feature/webfarm3.asp<BR><BR>but yeah there more of a headache...take the easy way out....again back to KISS

  9. #9
    Join Date
    Dec 1969
    Posts
    11,334

    Default RE: We already have solutions

    But would you agree that if you turned off &#039;enable sessions&#039; it would run a bit faster? The ONLY advantage I&#039;ve found using sessions over cookies (well, other than it takes less typing) is that you can jam an array or an object into a session var.

  10. #10
    Join Date
    Dec 1969
    Posts
    96,118

    Default Cookies vs. Session values...

    Don&#039;t forget, cookies are sent out across the net. Anybody with smarts can intercept them and analyze them. So don&#039;t put anything "secret" in them unless you encrypt it well!<BR><BR>But other than that...yeah, you&#039;re right.<BR><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
  •