I'll toss in a caveat that I have yet to lick...
With the client variable/WDDX scheme, although it works gangbusters, you
will run into big problems if and when a user spawns a new browser instance.
The server has no way of knowing this new spawn is to be given a separate
client store. When the user goes in two different directions with the two
instances (and who amongst us hasn't done that?), you end up with a mess on
the server side. Is Joe Shmoe adding an item to the cart or is he removing
one? Did he log out?
The only solution I know works in a controlled intranet environment. Tell
the users not to spawn multiple instances. That, however, is hardly a
solution.
Session scoping is a major hassle, what with the locking and all...
There is a workaround you could build into your app.
Basically, you can get away with doing a global find-n-replace with
"session."/"client.". Of course, save your work first!
Imagine, you could build in the WDDX serialize/deserialize component, and
use it even if you were doing session vars. A bit more overhead, but you at
least would be able to try both ways out.
Hm. I wonder (I know the answer but don't like it) if you can turn the scope
declaration into a variable! Imagine in your app_globals, <CFSET
my_scope="session">, and then you'd say my_scope.username, my_scope.id,
etcetera. Hoo that would be nice... Then you could flip it this way or that.
> -----Original Message-----
> From: Ryan Wood [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, April 03, 2001 4:34 AM
> To: Fusebox
> Subject: Speed for Persistant Variables
>
> I am developing a fusebox app that will need a large user structure on
> each
> page. That nested structure could be fairly large housing security,
> preferences, user data, etc. What is a best (most efficient) way of
> persisting that variable. I currently have a couple of options.
>
> 1. Use the session scope [downside = locking; upside = persisent in
> memory]
>
> 2. convert structure to WDDX packet and store as a client variable (using
> a
> database). Then in myGlobals (XFB) de-serialize the packet into a request
> scoped structure. [downside = need to de-serialize and set the request
> scope
> variable at the top of each page. upside = no locking]
>
> which option would provide the best speed, scalability, and use of memory?
> Is there another option that I am not seeing?
>
> Thanks.
>
> __
> Ryan Wood
> [EMAIL PROTECTED]
> SourceScape | www.sourcescape.com
> 864.346.3342
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
