«

Hi guys

I've come across a problem with cookies. It seems that if one attempts to
save several cookies in quick succession and then read them back again, you
may attempt to read a cookie that has not yet been saved from the first
operation. I assume that this is because JavaScript via the browser hands
the job over to the OS and then merrily proceeds upon its way.

As it happens, I solved the problem by rewriting my code to use one large
cookie that I could split into an array and hold as a global. I could then
manipulate it at will, and only when I had finished with it did I then
reassemble it into a string and then save it as a cookie in one shot.

Just as a matter of interest, I tried saving that same cookie and reading it
back immediately. The result came back as "undefined". But saving it and
then waiting a while (about 15 secs) and then reading it back, I got the
result I'd expected. I cleared the cookies before each test to make sure I
had clean results.

So my questions are this. Am I correct about the lag between JS and the OS?
Is there a methodical way of ensuring that a cookie has been written before
trying to read it back?

I hope I've explained that well enough. Many thanks for any advice.

Ian

In article <BD6548DA.CFC4%>,
enlightened us with...
> Hi guys
>
> I've come across a problem with cookies. It seems that if one attempts to
> save several cookies in quick succession and then read them back again, you
> may attempt to read a cookie that has not yet been saved from the first
> operation. I assume that this is because JavaScript via the browser hands
> the job over to the OS and then merrily proceeds upon its way.
>

I'm honestly not sure, but don't make that assumption. It could be that.
It could be that javascript is threaded. I never asked that question before,
so I'm not sure if it goes in threads or not. Which would mean that it breaks
off a child process to write the cookie while the main process keeps going.
It could be that the cookie isn't saved at all for a certain amount of time.
I know session cookies aren't saved to disk, so maybe it has to wait for the
OS to give it a place in dynamic memory or something. If it isn't a session
cookie, it may have to wait until a certain amount of data needs saved or
something before it writes to disk.
It could be another reason I'm not thinking of.

Just don't assume.

>
> So my questions are this. Am I correct about the lag between JS and the OS?

I dunno, but don't rule out other things.

> Is there a methodical way of ensuring that a cookie has been written before
> trying to read it back?
>

Not that I know of. I've never had this problem. Then again, I don't try to
store a lot of cookies, either. I store one cookie. The rest of the data I
want to associate with a user is stored on the server with the cookie ID as
the key.

--
--
~kaeli~
I love God.
It's His fanclub that I can't stand.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

> Not that I know of. I've never had this problem. Then again, I don't try to
> store a lot of cookies, either. I store one cookie. The rest of the data I
> want to associate with a user is stored on the server with the cookie ID as
> the key.


Yes, the cookie as a key to server data is what's planned and it'll be in
place by the end of next week. I came across this problem as I was
prototyping the pages that are going to be generated by SQL/ASP and I was
doing some crude simulations. I don't use cookies as a rule, either.

The question is purely academic, but many thanks for your input.

By the way, the idea that it might be because JavaScript it threaded is
definitely wrong. JavaScript isn't threaded.

Cheers

Ian