> Adam is right on when he says its bad advice to consider cookies as a
> blanket substitute for client variables. They exist for good reasons.
> I can remember back to earlier versions of CF where they added
> significant stability to a CF application versus session variables.
Actually I was referring to using cookies to *store* the Client scope:
<cfapplication clientStorage="Cookie" ... >
rather than migrating Client variables to cookies directly. Sorry if I
wasn't clear.
> However, CF has grown over time. You don't have to lock the use of
> session vars anymore (except in cases of race conditions -- fairly
> rare in a session scope) and as you say you have gobs of available
> memory.
Same exact criteria for locking as for the Server or Application scopes,
because the user might spawn another window from the same browser window or
the application might use frames. A race condition is a race condition, the
way I see it, and you have to lock then even if they are in the Session
scope.
> Client vars in a db work fine, but you are hitting your db a LOT with
> them, and under MX the benefits no longer outweigh this. There's no
> telling if lightening this db load and shifting it elsewhere will help
> you, but its certainly worth a try.
Storing Client vars in the database is sometimes the only thing you can do,
but it's a real performance killer, I assure you. That's one of the
seductive things about using clientStorage="Cookie" because it shifts that
burden to the clients, but being seduced can sometimes lead to downfall, as
I mentioned earlier about cookie data. These days we just try to steer
clear of Client variables altogether. I was just talking with Steve Drucker
about this a few weeks ago.
> Store your meaningless stuff in cookies. Only use them in cases where
> you will never need to set the cookie and read back from it within the
> same template. Never use them if you set them and cflocation to
> something else that needs to use the cookie value (both of these
> limitations can be overcome but why bother since...
Fixed in MX 6.1, IIRC.
> The above assumes you don't have situations where a race condition can
> arise. This should be a rare thing in the session scope, but if its
> there you *will* have to lock the writes (only) to the session scope.
There has been a lot of talk about locking writes but not reads, but if you
do this then your reads are no longer synchronized with your writes, even in
the Session scope. If a resource can be involved in a race condition, lock
both its writes and its reads. There is no compelling reason to not lock
reads.
Respectfully,
Adam Phillip Churvis
Member of Team Macromedia
http://www.ProductivityEnhancement.com
Download Plum and other cool development tools,
and get advanced intensive Master-level training:
* C# & ASP.NET for ColdFusion Developers
* ColdFusion MX Master Class
* Advanced Development with CFMX and SQL Server 2000
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Logware (www.logware.us): a new and convenient web-based time tracking
application. Start tracking and documenting hours spent on a project or with a
client with Logware today. Try it for free with a 15 day trial account.
http://www.houseoffusion.com/banners/view.cfm?bannerid=67
Message: http://www.houseoffusion.com/lists.cfm/link=i:4:205971
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
