This content has been marked as final. Show 10 replies
Cookies have a stated limit of 4K so this isn't an option (plus a lot of transfer overhead).
The Registry has it's place and unless you are dealing with a lot of traffic (which we're
not), it is a valid option. Saying never to use it for client variable storage ignores some
perfectly legitimate reasons for doing so.
I hate absolutes!
I was able to duplicate your problem using CF8 in Windows XP. It may be an issue with Windows rather than just a ColdFusion error since it's throwing a 234 error. You can test this by trying to grab the client variable with the cfregistry tag and dumping the catch
I'd certainly suggest moving your client storage to a database rather than the registry. Here's a link to a techNote that may be of help:
ColdFusion 4.5.1 SP2 and Up: Recommended settings for client variable storage
Thanks for taking the time to duplicate the problem. I've considered using the database
for the client variables and may go that route as an interim solution. The longer term
solution is to redesign things so I don't need to hang onto so much data as a client
variable in the first place! I would be curious if Adobe considers this a bug or just
trying to exceed an undocumented limit.
Regardless of how much data you're keeping in the client scope, it is a well-known best practice to move client vars out of the registry and into a database of some kind.
Using the registry for client variable storage is almost never a good idea. It's not scalable, it has serious limitations, and after a while it will slow your server down to a crawl.
You can usually get away with it on really small web sites, or a local test environment...but for any true production web site, the database is the #1 recommended storage location for client vars.
If you google around for a bit on the subject you'll see what I mean.
Best of luck with it!
Just to second (third... fourth...) everyone else's commment about the
registry not being a very good place for client vars,under any
Once upon a time I had to reinstall my dev laptop because the volume of
client variables accumulating in the registry swapped it, and caused the
registry to die. It was sufficiently dead that I could not actually clear
the rubbish out (nor do anything else which required writing to the
registry). And this is an enviroment in which we really don't use client
variables for much, but what went in was never cleared properly.
Now... this was on an older version of CF (6.1, probably), and maybe this
has been sorted in the interim. But "once bit, twice shy" as the addage
goes; I've never revisited the situation, instead always using a DSN
For your purposes, I would not be storing any actual DATA in your client
variables, I would simply be storing a key to identify the user. And
storing the data relating to the key in the DB. This prevents
out-of-control growth of the client variable.
Don't get me wrong, I GET using an external database for client variable storage. I've read the best practice guides and agree with them. What I disagree with is that using the registry has no place. I've been developing CF applications since O'Reilly was giving it away for free with their webserver (I bet few people remember those days :). Most of my applications are intranet apps for companies where were talking no more than a few hundred unique users and a relatively low level of activity when compared to popular Internet sites. When the registry cleanup process is set properly, and the registry is sized appropriately, for SOME applications it IS a perfectly legitimate choice. The registry is a database is it's own right and just like any other data repository (and yes, I've been a DBA working on hierarchical, network, and relational databases with millions of transactions a day so I understand databases :) it needs to be managed correctly.
Trying to get this thread back on track, IF one chooses to use the registry for client variable storage, Adobe should either work to correct this bug or at least document that 4K is the size limit.
I know what you're saying editcorp, but don't most web sites have a database available anyways? I could understand the argument if for some reason you were working in a restricted environment where no database was available. But if you have a database available to you, I don't see why someone would ever opt for the registry over a real DBMS. Why take the stairs when there's a perfectly good elevator? :)
In any event, I know how frustrating it can be when you trip over an undocumented limitation in a software feature...but I highly doubt this limitation is anywhere on Adobe's radar to fix, or document. Coming from a software company myself, I know how quickly these low priority issues can fall off the radar.
The truth is most people don't use the registry for client variable storage, for reasons that we've already covered. And for the small number of people that are, they certainly aren't going to be storing 4K+ worth of data per client. Generally speaking, anyone that is *heavily* using client vars is going to be wise enough to store them in a database.
Saying never to use it for client variable storage ignores some perfectly legitimate reasons for doing so
Tech Note: Troubleshooting client variable issues on Windows
There are many variations of hangs on production systems related to client variable use with the Windows Registry. The Windows Registry is not supported for production applications.
Tech Note: Deleting client variables stored in the Registry
By default, ColdFusion stores client variables in the Registry. This can cause performance degradation in high-traffic sites as the Registry will increase considerably in size, causing ColdFusion server instability. Macromedia recommends storing client variables in an enterprise RDBMS.
Tech Note: Debugging thread dumps and server problems...
Registry client storage should never be used for production systems but often developers fall into this by accident by not explicitly specifying a data source (and the ColdFusion admin defaulting to "REGISTRY"). Since the registry isn't a real database, ColdFusion has to retrieve the entire registry client tree (high memory usage) and compare the date/time one at a time to decide whether to purge a record. This is a CPU-intensive operation with an hourly purge that may only delete a few records.
Sometimes never does mean never. Of course, that makes one wonder why it is the default selection for client storage.... You seem to believe that you have a legitimate reason to use the registry, so I guess that you are willing to live with the consequences.
Of course, that makes one wonder why it is the default selection for client storage
Yes, doesn't it.