Don't use the Client scope! There are only a few reasons to use Client scope and I would still think long and hard about it after having maintained an application that was almost purely Client scope for user state.  I think you should avoid the client scope unless you have a real and hard requirement that you absolutely can't lose session data in the event of a server failure. I admit, it is kind of nice to still have all of your user sessions when you restart CF and that benefited our applications in some cases. However, I still don't think the benefits for Client scope are not worth it. Sticky sessions are OK in a load balanced situation. You may get some uneven clumping of clients in some cases, but in reality it turns out not to be a big deal. Playing with WDDX and the overheads involved in that and the pain of keeping track of the serialization state of your data just isn't worth it.

You can't even serialize a CFC with WDDX, but they will happily live in the session scope. If you do use client scope make sure you abstract it with a good layer around it so that what scope you use is transparent to your application so that you can change it in the future without your application noticing. Look to the Facade design pattern for that.

Jeremy

On 9/27/06, Teddy Payne <[EMAIL PROTECTED]> wrote:
Allen made a good point about WDDX.  I tend to overlook CFWDDX.

<cfwddx action = "" input = "#session#" output="client.foo">

<cfdump var="#client.foo#"> can dump your session into foo variable stored into the client scope.

Your result in the DB would look similar to:
foo=<wddxPacket version#='1.0'><header/><data><struct type#=' coldfusion.runtime.MemorySessionScope'><var name#='cftoken'><string>88107569</string></var><var name#='urltoken'><string>CFID#=7101&amp;CFTOKEN#=88107569</string></var><var name#='cfid'><string>7101</string></var><var name#='sessionid'><string>TESTAPP_7101_88107569</string></var></struct></data></wddxPacket>#

Teddy

On 9/27/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Just as an aside - you can still store complex structures in client variables but you'll have to wddx them into a string and then store them into the client variable.  Also, if you do this and you have your client variables stored in the database, you'll want to make sure your datasource is enabled to retrieve BLOB's without the 64k limit.
 
One other thing, if you're running on MX in JRUN configuration (not standalone), you can share the sessions between servers (if I remember right).  J2EE has clustering built in and I believe it supports the equivalent of a session state server. 
 
Allen
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of [EMAIL PROTECTED]
Sent: Wednesday, September 27, 2006 9:22 AM
To: discussion@acfug.org
Subject: Re: Re: [ACFUG Discuss] Client? Session?


In general it seems to me that the rule is that once a user is on a server, they are on the same server.  Define complex data.  I potentially see structures and possibly an occasional object in the shared scope, but honestly I don't know yet.  We don't officially have any code written.  

mcg




Steven Ross <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]

09/26/2006 08:04 PM

Please respond to
discussion@acfug.org

To
discussion@acfug.org
cc

Subject
Re: Re: [ACFUG Discuss] Client? Session?







Yeah it depends on how you want your requests routed... it is my
understanding that if you want the machines to round robin each
request then you need to do client variables, if you don't care and
you just want users to stay on one server then you can use sessions.

On 9/26/06, Teddy Payne <[EMAIL PROTECTED]> wrote:
> Are you looking to store complex data in your shared scope?  If so, you need
> some sort of sticky session solution.  If you are looking to store simple
> data, using the datasource option of client variable storeage would make it
> easier to switch over between servers.
>
> Teddy
>
>
> On 9/26/06, [EMAIL PROTECTED] <
> [EMAIL PROTECTED]> wrote:
> >
> > I'm a little confused as to what scope of variables to use in our
> situation.  We have a primary server and a 'backup' server in case the
> primary fails.  Now that is the current situation.  Eventually the backup
> will be replaced with a better machine and the load will be balanced a
> little more evenly.   Currently the balancing is done via Resonate software
> (and no one seems to like it).  As far as 100% failover, I really don't see
> that as a necessity, these aren't banking applications.  Also these servers
> don't talk to each other that I know of.
> >
> > TIA
> >
> > Mary-Catherine
> >
> -------------------------------------------------------------
> > To unsubscribe from this list, manage your profile @
> > http://www.acfug.org?fa=login.edituserform
> >
> > For more info, see http://www.acfug.org/mailinglists
> > Archive @
> http://www.mail-archive.com/discussion%40acfug.org/
> > List hosted by FusionLink
> >
> -------------------------------------------------------------
>
>
>
> --
> <cf_payne />
>
> Blog: http://cfpayne.wordpress.com/
> Atlanta CFUG: http://www.acfug.org
>
> -------------------------------------------------------------
> To unsubscribe from this list, manage your profile @
> http://www.acfug.org?fa=login.edituserform
>
> For more info, see http://www.acfug.org/mailinglists
> Archive @
> http://www.mail-archive.com/discussion%40acfug.org/
> List hosted by FusionLink
> -------------------------------------------------------------


--
Steven Ross
web application & interface developer
http://www.zerium.com
[mobile] 404-488-4364
[fax] 928-484-4364


-------------------------------------------------------------
To unsubscribe from this list, manage your profile @
http://www.acfug.org?fa=login.edituserform

For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by http://www.fusionlink.com
-------------------------------------------------------------





-------------------------------------------------------------
To unsubscribe from this list, manage your profile @
http://www.acfug.org?fa=login.edituserform

For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by FusionLink
-------------------------------------------------------------

-------------------------------------------------------------

To unsubscribe from this list, manage your profile @
http://www.acfug.org?fa=login.edituserform

For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by FusionLink
-------------------------------------------------------------



--

<cf_payne />

Blog: http://cfpayne.wordpress.com/
Atlanta CFUG: http://www.acfug.org
-------------------------------------------------------------
To unsubscribe from this list, manage your profile @
http://www.acfug.org?fa=login.edituserform

For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by FusionLink
-------------------------------------------------------------


-------------------------------------------------------------
To unsubscribe from this list, manage your profile @
http://www.acfug.org?fa=login.edituserform

For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by FusionLink
-------------------------------------------------------------

Reply via email to