are session variable id's unique?

Results 1 to 5 of 5

Thread: are session variable id's unique?

  1. #1
    Shilohcity Guest

    Default are session variable id's unique?

    Well I guess my title here explains my query. I am wanting to use a session id as a unique identifier in a table. Is this possible or recommended?<BR><BR>If it is not suitable I am planning on entering info in a table which will occupy more than one row (different items from a cart) and using the autonumber field of the first item as the unique order number something like this:<BR><BR>RS.Open orderinfo, objConn, adOpenKeySet, adLockOptimistic, adCmdTable<BR>RS.AddNew<BR>RS("itemid") = Request(“itemid”)<BR>RS("quantity") = Request(“quantity”)<BR>RS("sessionid") = Request(“sessionid”)<BR>RS.Update<BR>orderid = RS("autonumber")<BR><BR>this would get me the number but the first item added would still have an empty orderid column so..<BR><BR>Set objRS = Nothing<BR>Sql = SELECT * FROM orderinfo WHERE orderid = ("&orderid&")<BR> sql<BR>Rs(“orderid”) = orderid<BR><BR>and then pass the orderid to a hidden field and on we go..<BR> <BR><BR>Any feedback very welcome<BR><BR>Justin.

  2. #2
    Join Date
    Dec 1969

    Default RE: are session variable id's unique?

    they&#039;re unique as long as the server is still running, apparently. I&#039;ve been told you shouldn&#039;t use them in tables, There&#039;s a paragraph on it in Wrox&#039;s ASP Programmers Guide<BR><BR>j

  3. #3
    Join Date
    Dec 1969

    Default Only for the time the application is running...

    Consider: Sesssion.SessionID returns a 32-bit number. There are only 4 billion possible values in 32 bits.<BR><BR>Now 4 billion is a pretty damned big number, but it is *not* infinity!<BR><BR>And if you restart an application (e.g., the server crashed, or you changed the GLOBAL.ASA file or or or), the system picks a random number (from the 4 billion) to start at. It is *unlikely* but certainly not impossible that the restart might start just before or in the middle of a range of numbers used last time the app was running. So you *could* hit a duplicate.<BR><BR>The generally recommended way to guarantee a truly unique ID is to combine a date/time stamp with the Sesssion.SessionID. It is certainly impossible that any such pair of values could be duplicated, and the code is easy.<BR><BR>&#060;%<BR>...<BR>RS("idPart1") = Session.SessionID<BR>RS("idPart2") = Now<BR>...<BR>%&#062;<BR><BR>Eh?<BR><BR>

  4. #4
    Mike Shaffer Guest

    Default I dunno, Bill...

    &nbsp;<BR>&#062;&#062;It is certainly impossible that any such <BR>&#062;&#062;pair of values could be duplicated, and <BR>&#062;&#062;the code is easy. <BR><BR>4,294,967,296 * 1,200,000 (assuming 20 minute session timeout) is a pretty damned big number, but it is *not* infinity! ;-)<BR>

  5. #5
    Join Date
    Dec 1969

    Default Technically, you are correct, but...

    Where did you come up with your multipliers?<BR><BR>4,294,967,296 is the number of Session.SessionID&#039;s I grant you.<BR><BR>But why only 1,200,000 possible time stamps? If you use the "Now" function to get the time, it is accurate to roughly the millisecond and is monotonically increasing (well, assuming no idiot resets the system clock to some date in the past).<BR><BR>So look at the other way around:<BR><BR>What you are *actually* doing is making the primary ID be the current time stamp, accurate to the millisecond, and the Sesssion.SessionID is simply a tie-breaker in case two people ended up with exactly the same time stamp. (And, actually, there are easy ways of preventing that, so that you wouldn&#039;t even need the Session.SessionID value.)<BR><BR>Now, I said you are technically correct because, under the covers, the timestamp is a DOUBLE number, where the integer part represents the number of days since 1/1/1900 (and is negative for earlier dates) and the fractional part represents the fraction of the 24-hour day. <BR><BR> a few trillion years?...the integer part needed to represent the current day will end up using so many bits of the DOUBLE that the fractional part will barely be able to distinguish what hour it is. [Do you follow that? See how the bits have to be used?]. At which point you could, presumably, restart the server and, still by pretty incredible coincidence, end up with a duplicated number.<BR><BR>If you push me hard, I&#039;ll get out my calculator and figure out when that will happen. But the practicality of the numbers says that the Universe will have reverted to a nearly homogeneous mass at about 1.7 degrees Kelvin by the time that happens.<BR><BR>In the meantime, the only way for it to happen is to be able to restart the server in significantly less than a millisecond so that a person at the end of application period 1 happens to have *exactly* the same time as a person at the beginning of application period 2...*AND* then hits the same 1 out of 4,000,000,000 Session.SessionID.<BR><BR>Okay, it&#039;s not inifinity. But until you start guaranteeing we&#039;ll all live for billions (or more?) years, I&#039;m not going to worry about it.<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