subject:"RE\: Session VS Client"

Re: session vs. client scope (clustering)

2013-11-15 Thread Russ Michaels

client variables are pretty rubbish as they can only hold simple values.
If that is all you need it for, then perhaps use it, but I would restricr
usage to COOKIE storage, registry should be avoided at all cost, and
database storage can really put a lot of extra load on the database and
delays on execution time.
If your cluster is setup properly then it will be using sticky sessions
anyway, so speak with sysadmin and ask him.

you may want to read this
http://www.dopefly.com/pages/ColdFusionClientVariablesFinalNail.cfm

On Fri, Nov 15, 2013 at 2:41 PM, Brian FitzGerald
wrote:

>
> Hey guys,
>
> In my applications, I have always used the session scope for handy things
> like storing the currently logged in user, so I can just do:
> user.isLoggedIn() ... user.hasRole("admin"), things like that. It's great!
>
> Here at my current gig, though, they have a clustered server configuration
> so they are using client variables rather than the session scope. In
> configurations like this (which certainly must be very common), is there a
> standard best practice?
>
> If I wanted to have a user object available on every page request, for
> example, would I need to serialize and deserialize it w/ wddx on every
> request (seems nasty), or perhaps I just store the userID in client.userID
> and at the start of every request call
> userService.getUserById(client.userID) (seems like extra overhead), or
> maybe I should look into something like "sticky sessions"?
>
> I have experience in application design, but not as much with server
> configuration and clustering so I'm not sure how this is normally solved.
> Thanks in advance for your insight!
>
> 

~|
Order the Adobe Coldfusion Anthology now!
http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion
Archive: 
http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:357080
Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm
Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm

Re: session vs. client scope (clustering)

2013-11-15 Thread Dave Watts


> In my applications, I have always used the session scope for handy things 
> like storing the currently logged in
> user, so I can just do: user.isLoggedIn() ... user.hasRole("admin"), things 
> like that. It's great!
>
> Here at my current gig, though, they have a clustered server configuration so 
> they are using client variables
> rather than the session scope. In configurations like this (which certainly 
> must be very common), is there a
> standard best practice?
>
> If I wanted to have a user object available on every page request, for 
> example, would I need to serialize and
> deserialize it w/ wddx on every request (seems nasty), or perhaps I just 
> store the userID in client.userID and
> at the start of every request call userService.getUserById(client.userID) 
> (seems like extra overhead), or maybe
> I should look into something like "sticky sessions"?

There isn't really anything that rises to the level of a best practice
here. Instead, different application environments have different
desired outcomes.

Are you using clustering to support a larger number of users than a
single server? Or are you using it to provide failover in case a
server fails? Or both?

If the former, there's nothing wrong with using sticky sessions, and
you won't have to change your code.

If the latter, you have two choices. You could use the Client scope as
described above, or you could set up session replication between the
servers. Session replication would let you continue using the same
approach in your code, but is somewhat difficult and fragile, so I try
to avoid using it. On the other hand, the Client scope is slower, and
requires the serialization approach you describe if you want to use
objects. That said, it usually performs adequately, and while the
serialization may seem "nasty", you don't typically have to revisit
this code once it's written, and you can hide it away from your actual
implementation of objects.

I'm not sure where your userService object would live on a cluster of
servers, in a way that would allow it to have the same data, without
doing things of equal or greater nastiness. So I'd probably just
serialize objects, but I'd want to make sure that I'm not storing too
much in these objects due to the overhead of this process.

Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
http://training.figleaf.com/

Fig Leaf Software is a Veteran-Owned Small Business (VOSB) on
GSA Schedule, and provides the highest caliber vendor-authorized
instruction at our training centers, online, or onsite.

~|
Order the Adobe Coldfusion Anthology now!
http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion
Archive: 
http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:357079
Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm
Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm

Re: Session vs. Client Variables

2004-12-30 Thread Chris Norloff

We just switched away from client variables, and now use only session 
variables. We got an enormous increase in performance. The database guys were 
complaining about the performance impace from all the reads -- let alone the 
writes -- due to storing variables in the database.

Recall that CFMX (like CF before it) reads all the user's client variables at 
the beginning of any HTTP Request that uses even one client variable. All the 
user's client variables are then written back to the database at the end of 
that HTTP Request. 

We definitely experienced some issues with scaling. (CFMX for J2EE, WebSphere, 
Oracle 10g, 3,000 to 4,000 concurrent users, database-intensive application)

Chris Norloff

-- Original Message --
From: <[EMAIL PROTECTED]>
... 
>But as a test, I tried switching to client variables (using database)
>and we took a serious performance hit (probably 50%) with the current
>application. I'll do my best to streamline it during the rewrite, but
>does anyone have any suggestions on the best route to take here?
> 
>Thanks,
>Jonathan
...

~|
Special thanks to the CF Community Suite Gold Sponsor - CFHosting.net
http://www.cfhosting.net

Message: http://www.houseoffusion.com/lists.cfm/link=i:4:189007
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

Re: SESSION vs. CLIENT

2004-09-29 Thread Adam Churvis

Calvin,

He's using a BigIP hardware load balancer, so there's a good chance that he
can outrun the J2EE session replication mechanism between requests.  This
isn't talked about a lot, but it happens.

Using Client variables stored in either cookies or a database shared by the
clustered servers eliminates potential "undefined in Session scope" errors
because ColdFusion either receives all Client variables in the request
(cookie) or ColdFusion waits until retrieval and parsing of the Client
variable has happened (database).

Note: before choosing to store Client variables in cookies (seductive
because it is the fastest technique by far), make sure you're not storing
any secure data in the Client scope.  You wouldn't believe how many
developers forget this; you can spoof cookies that will take you right into
their admin sections.  Also make sure the total size of your Client scope
won't bust any cookie size or quantity limitations.

Respectfully,

Adam Phillip Churvis
Member of Team Macromedia

Advanced Intensive Training:
* C# & ASP.NET for ColdFusion Developers
* ColdFusion MX Master Class
* Advanced Development with CFMX and SQL Server 2000
http://www.ColdFusionTraining.com

Download CommerceBlocks V2.1 and LoRCAT from
http://www.ProductivityEnhancement.com

The ColdFusion MX Bible is in bookstores now!
- Original Message - 
From: "Calvin Ward" <[EMAIL PROTECTED]>
To: "CF-Talk" <[EMAIL PROTECTED]>
Sent: Wednesday, September 29, 2004 9:59 AM
Subject: RE: SESSION vs. CLIENT

> The short answer is that there can be need for both depending on the
situation.
>
> With CFMX Enterprise, you can leverage J2EE Sessions, that will allow you
to duplicate sessions across a cluster.
>
> Sessions have the advantage of being able to store complex data types, and
don't involve a call to a database.
>
>
> However, I've seen CF apps with client variables in a database in a
clustered non-sticky environment work well.
>
>
> I would lean towards the J2EE duplicating sessions as a solution
personally. You can read more about it at www.bpurcell.org.
>
> - Calvin
>
> -Original Message-
> From:  Al Everett
> Date:  9/29/04 9:51 am
> To:  CF-Talk
> Subj:  SESSION vs. CLIENT
>
> We're working in a clustered environment (eight servers in one pool, two
> in several others) on Windows 2000/IIS 5.0 behind a BigIP load balancer
> with some CF5 and some CFMX. (Very soon to go all CFMX.)
>
> We use Session variables extensively to keep track of user's logon
> information, which has required us to use "stick sessions" on the load
> balancer to keep users stuck to a server. However, we've gone through
> several exercises with certain customers because of the way their proxy
> servers/firewall block or trap cookies or other issues.
>
> I have suggested that if we were to go to Client variables in a database
> for that information we would remove the need for sticky sessions. The
> argument against me has always been that a database transaction is too
> expensive. Back before our database was tuned and we resolved a bunch of
> network issues I would have agreed, but we're almost guaranteed to have
> at least one call to the database on every page load right now and the
> site is fine. (Oracle 9i running on Solaris.)
>
> Does anybody have any good statistical and/or anecdotal evidence on
> whether Sesssion is better or worse than Client variables, specifically
> in CFMX6.1?
>
>
>
> ___
> Do you Yahoo!?
> Express yourself with Y! Messenger! Free. Download now.
> http://messenger.yahoo.com
>
>
>
>
 [Todays Threads] 
 [This Message] 
 [Subscription] 
 [Fast Unsubscribe] 
 [User Settings]
 [Donations and Support]

RE: SESSION vs. CLIENT

2004-09-29 Thread Calvin Ward

The short answer is that there can be need for both depending on the situation.

With CFMX Enterprise, you can leverage J2EE Sessions, that will allow you to duplicate sessions across a cluster.

Sessions have the advantage of being able to store complex data types, and don't involve a call to a database.

However, I've seen CF apps with client variables in a database in a clustered non-sticky environment work well.

I would lean towards the J2EE duplicating sessions as a solution personally. You can read more about it at www.bpurcell.org.

- Calvin

-Original Message-
From: Al Everett
Date: 9/29/04 9:51 am
To: CF-Talk
Subj: SESSION vs. CLIENT

We're working in a clustered environment (eight servers in one pool, two
in several others) on Windows 2000/IIS 5.0 behind a BigIP load balancer
with some CF5 and some CFMX. (Very soon to go all CFMX.)

We use Session variables extensively to keep track of user's logon
information, which has required us to use "stick sessions" on the load
balancer to keep users stuck to a server. However, we've gone through
several exercises with certain customers because of the way their proxy
servers/firewall block or trap cookies or other issues.

I have suggested that if we were to go to Client variables in a database
for that information we would remove the need for sticky sessions. The
argument against me has always been that a database transaction is too
expensive. Back before our database was tuned and we resolved a bunch of
network issues I would have agreed, but we're almost guaranteed to have
at least one call to the database on every page load right now and the
site is fine. (Oracle 9i running on Solaris.)

Does anybody have any good statistical and/or anecdotal evidence on
whether Sesssion is better or worse than Client variables, specifically
in CFMX6.1?

___
Do you Yahoo!?
Express yourself with Y! Messenger! Free. Download now.
http://messenger.yahoo.com
[Todays Threads]
[This Message]
[Subscription]
[Fast Unsubscribe]
[User Settings]
[Donations and Support]

RE: Session vs. Client Management

2004-01-28 Thread Andrew Scott

client and session vars are all session controlled by CFID & CFToken, the
same thing applies.

 
I use client and never use session vars, and I think you may find that your
cookies are not enabled and that is why you can get  what your getting.

 
Do you have a firewall in place, like Norton Internet Security or something
else that is turning your cookies off.

Regards
Andrew Scott
Technical Consultant

NuSphere Pty Ltd
Level 2/33 Bank Street
South Melbourne, Victoria, 3205

Phone: 03 9686 0485  -  Fax: 03 9699 7976   

  _  

From: Philip Arnold [mailto:[EMAIL PROTECTED] 
Sent: Thursday, 29 January 2004 12:35 PM
To: CF-Talk
Subject: RE: Session vs. Client Management

The funny thing about this is, we don't use Session management that
often, so I'm used to using Client variables

If I open a browser, create some client variables - then Ctrl+N a new
window, the client variables are copied across, or shared

Now, if I open a brand new browser (from the start menu), it doesn't
have the client vars in it 
  _
 [Todays Threads] 
 [This Message] 
 [Subscription] 
 [Fast Unsubscribe] 
 [User Settings]

RE: Session vs. Client Management

2004-01-28 Thread Philip Arnold

> Actually that is not true Phil, I made a statement about this 
> a few weeks ago.
>  
> Under Internet Explorer, the cookies are not copied across. 
> Internet explorer uses instances of windows and shares the 
> data/settings of the windows control panel->Internet Options.
>  
> Anytime you open a new browser either by ctrl-n or from the 
> start menu it will use these settings. I think this change 
> from V4.0 of internet explorer, to cut down on the amount of 
> memory used by the program.
>  
> Cookies will only expire like Dave Watts said, you expire them.
>  
> Try it for yourself, write a small app that puts the cfid & 
> cftoken to the screen nothing more nothing less. Then try 
> opening a new window via both methods and you will see the 
> cfid & cftoken DO NOT change. If they do then cookies are not 
> enabled on your machine, simple as that.

The funny thing about this is, we don't use Session management that
often, so I'm used to using Client variables

If I open a browser, create some client variables - then Ctrl+N a new
window, the client variables are copied across, or shared

Now, if I open a brand new browser (from the start menu), it doesn't
have the client vars in it
 [Todays Threads] 
 [This Message] 
 [Subscription] 
 [Fast Unsubscribe] 
 [User Settings]

RE: Session vs. Client Management

2004-01-28 Thread Andrew Scott

Actually that is not true Phil, I made a statement about this a few weeks
ago.

 
Under Internet Explorer, the cookies are not copied across. Internet
explorer uses instances of windows and shares the data/settings of the
windows control panel->Internet Options.

 
Anytime you open a new browser either by ctrl-n or from the start menu it
will use these settings. I think this change from V4.0 of internet explorer,
to cut down on the amount of memory used by the program.

 
Cookies will only expire like Dave Watts said, you expire them.

 
Try it for yourself, write a small app that puts the cfid & cftoken to the
screen nothing more nothing less. Then try opening a new window via both
methods and you will see the cfid & cftoken DO NOT change. If they do then
cookies are not enabled on your machine, simple as that.

Regards
Andrew Scott
Technical Consultant

NuSphere Pty Ltd
Level 2/33 Bank Street
South Melbourne, Victoria, 3205

Phone: 03 9686 0485  -  Fax: 03 9699 7976   


  _  

From: Philip Arnold [mailto:[EMAIL PROTECTED] 
Sent: Thursday, 29 January 2004 1:41 AM
To: CF-Talk
Subject: RE: Session vs. Client Management

> By default, this is incorrect. The CFID and CFTOKEN cookies 
> are persistent, and have a ridiculously long time until they 
> expire. If you want the connection to the session to be 
> destroyed when the browser is closed, you need to write the 
> cookies yourself without specifying an expiration value in 
> your CFCOOKIE tags, or use the J2EE session option available
> in CFMX.

I'm not sure of this, because if you close all browsers, then the
cookies are lost

I know that if you Ctrl+N/File, New or Open Link In New Window, then it
copies the cookies over to the new browser, but opening a brand new
browser (from the Start Menu (or Shortcut) then they don't exist 
  _
 [Todays Threads] 
 [This Message] 
 [Subscription] 
 [Fast Unsubscribe] 
 [User Settings]

RE: Session vs. Client Management

2004-01-28 Thread Andrew Scott

That's ok just saying that you had mislead nothing meant by it:-)

Regards
Andrew Scott
Technical Consultant

NuSphere Pty Ltd
Level 2/33 Bank Street
South Melbourne, Victoria, 3205

Phone: 03 9686 0485  -  Fax: 03 9699 7976   

  _  

From: Philip Arnold [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, 28 January 2004 11:41 PM
To: CF-Talk
Subject: RE: Session vs. Client Management

> Phil has led you astray a little here and I will correct him.

That's why I said it was from memory and I may be wrong  
  _
 [Todays Threads] 
 [This Message] 
 [Subscription] 
 [Fast Unsubscribe] 
 [User Settings]

Milestone (was RE: Session vs. Client Management)

2004-01-28 Thread Cary Gordon

I have been archiving Dave's posts since 11/18/1999.  This is number 5,000.

Cary Gordon
The Cherry Hill Company

At 12:54 PM 1/28/2004 -0500, you wrote:
> > It must tie it to the SessionTimeout in the CFAdmin and
> > CFAPPLICATION then
>
>If by "it" you mean the duration of the cookies, no, by default they last a
>very long time.
>
>Dave Watts, CTO, Fig Leaf Software
>http://www.figleaf.com/
>phone: 202-797-5496
>fax: 202-797-5444
 [Todays Threads] 
 [This Message] 
 [Subscription] 
 [Fast Unsubscribe] 
 [User Settings]

RE: Session vs. Client Management

2004-01-28 Thread Dave Watts

> It must tie it to the SessionTimeout in the CFAdmin and 
> CFAPPLICATION then

If by "it" you mean the duration of the cookies, no, by default they last a
very long time.

Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
phone: 202-797-5496
fax: 202-797-5444
 [Todays Threads] 
 [This Message] 
 [Subscription] 
 [Fast Unsubscribe] 
 [User Settings]

RE: Session vs. Client Management

2004-01-28 Thread Philip Arnold

It must tie it to the SessionTimeout in the CFAdmin and CFAPPLICATION
then

Maybe some testing is required 

> -Original Message-
> From: Dave Watts [mailto:[EMAIL PROTECTED] 
> Sent: 28 January 2004 12:14
> To: CF-Talk
> Subject: RE: Session vs. Client Management
> 
> 
> > > By default, this is incorrect. The CFID and CFTOKEN cookies
> > > are persistent, and have a ridiculously long time until they 
> > > expire. If you want the connection to the session to be 
> > > destroyed when the browser is closed, you need to write the 
> > > cookies yourself without specifying an expiration value in 
> > > your CFCOOKIE tags, or use the J2EE session option available
> > > in CFMX.
> > 
> > I'm not sure of this, because if you close all browsers, then the 
> > cookies are lost
> 
> They're not on any of the machines in my classroom right now. 
> I can close and reopen browsers all day long, and the cookies 
> are still there. We did this as a student exercise yesterday, 
> to demonstrate the difference between CFID/CFTOKEN and J2EE 
> session management.
> 
> > I know that if you Ctrl+N/File, New or Open Link In New
> > Window, then it copies the cookies over to the new browser, but 
> > opening a brand new browser (from the Start Menu (or Shortcut) 
> > then they don't exist
> 
> If the cookies persisted from a previous session, I think 
> they'll be available for all browser instances whether you 
> open a brand new browser instance or not.
> 
> Dave Watts, CTO, Fig Leaf Software
> http://www.figleaf.com/
> phone: 202-797-5496
> fax: 202-797-5444
> 
>
 [Todays Threads] 
 [This Message] 
 [Subscription] 
 [Fast Unsubscribe] 
 [User Settings]

RE: Session vs. Client Management

2004-01-28 Thread Dave Watts

> > By default, this is incorrect. The CFID and CFTOKEN cookies 
> > are persistent, and have a ridiculously long time until they 
> > expire. If you want the connection to the session to be 
> > destroyed when the browser is closed, you need to write the 
> > cookies yourself without specifying an expiration value in 
> > your CFCOOKIE tags, or use the J2EE session option available
> > in CFMX.
> 
> I'm not sure of this, because if you close all browsers, then the
> cookies are lost

They're not on any of the machines in my classroom right now. I can close
and reopen browsers all day long, and the cookies are still there. We did
this as a student exercise yesterday, to demonstrate the difference between
CFID/CFTOKEN and J2EE session management.

> I know that if you Ctrl+N/File, New or Open Link In New 
> Window, then it copies the cookies over to the new browser, but 
> opening a brand new browser (from the Start Menu (or Shortcut) 
> then they don't exist

If the cookies persisted from a previous session, I think they'll be
available for all browser instances whether you open a brand new browser
instance or not.

Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
phone: 202-797-5496
fax: 202-797-5444
 [Todays Threads] 
 [This Message] 
 [Subscription] 
 [Fast Unsubscribe] 
 [User Settings]

RE: Session vs. Client Management

2004-01-28 Thread Philip Arnold

> By default, this is incorrect. The CFID and CFTOKEN cookies 
> are persistent, and have a ridiculously long time until they 
> expire. If you want the connection to the session to be 
> destroyed when the browser is closed, you need to write the 
> cookies yourself without specifying an expiration value in 
> your CFCOOKIE tags, or use the J2EE session option available
> in CFMX.

I'm not sure of this, because if you close all browsers, then the
cookies are lost

I know that if you Ctrl+N/File, New or Open Link In New Window, then it
copies the cookies over to the new browser, but opening a brand new
browser (from the Start Menu (or Shortcut) then they don't exist
 [Todays Threads] 
 [This Message] 
 [Subscription] 
 [Fast Unsubscribe] 
 [User Settings]

RE: Session vs. Client Management

2004-01-28 Thread Philip Arnold

> Phil has led you astray a little here and I will correct him.

That's why I said it was from memory and I may be wrong 
 [Todays Threads] 
 [This Message] 
 [Subscription] 
 [Fast Unsubscribe] 
 [User Settings]

RE: Session vs. Client Management

2004-01-27 Thread Dave Watts

> The CFID and CFTOKEN variables are ALWAYS on the "session" 
> level, so as soon as you close the browser, they go

By default, this is incorrect. The CFID and CFTOKEN cookies are persistent,
and have a ridiculously long time until they expire. If you want the
connection to the session to be destroyed when the browser is closed, you
need to write the cookies yourself without specifying an expiration value in
your CFCOOKIE tags, or use the J2EE session option available in CFMX.

Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
phone: 202-797-5496
fax: 202-797-5444
 [Todays Threads] 
 [This Message] 
 [Subscription] 
 [Fast Unsubscribe] 
 [User Settings]

RE: Session vs. Client Management

2004-01-27 Thread Andrew Scott

Jim,

 
The purge clients that remain unvisited has been around in Coldfusion since
4.0 that I can recall. I can't recall the earlier versions as my memory
can't go past 1998 on this fact

Regards
Andrew Scott
Technical Consultant

NuSphere Pty Ltd
Level 2/33 Bank Street
South Melbourne, Victoria, 3205

Phone: 03 9686 0485  -  Fax: 03 9699 7976
 [Todays Threads] 
 [This Message] 
 [Subscription] 
 [Fast Unsubscribe] 
 [User Settings]

RE: Session vs. Client Management

2004-01-27 Thread Andrew Scott

Jim,

 
Phil has led you astray a little here and I will correct him.

 
CFID & CFToken are used to identify which variables belong to that client,
which is held in memory and controlled by the cookie. If the cookie has
expiration then closing the browser will assign new values for CFID &
CFToken. Otherwise the next time they log in the cookie will keep these
available until this cookie does expire.

 
There is no difference in the cookie that CF uses for client or session,
CFID & CFToken are references for that client. Change them and they get
reset to nothing, but are still held in the system until manually deleted or
they expire by the server settings.

 
Client variables are supposed to be cleaned up by CF, however I am yet to
see CF clean the client variables up when stored in a DB. I don't use the
registry for  client variables so I can't say if they do clean up or not.
But there is a setting in the Administrator to change the length of time
before deleting this.


Regards
Andrew Scott
Technical Consultant

NuSphere Pty Ltd
Level 2/33 Bank Street
South Melbourne, Victoria, 3205

Phone: 03 9686 0485  -  Fax: 03 9699 7976   

  _  

From: Jim McAtee [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, 28 January 2004 12:43 PM
To: CF-Talk
Subject: Session vs. Client Management

Been using CF for so long, I should know these things without thinking.  I'm
guessing I may even have known the answers at one time...

If a cfapplication has session, but not client management enabled (and is
using client cookies), then is there any difference in the cookie that CF
uses?  Expiration date, for instance.

How does CF keep track of sessions?  I realize it uses the CFID/CFTOKEN
combo
set in a cookie or in the url, but where does it keep session tracking
information and session variables?  In memory?  All sessions are lost if the
cf application service is restarted, correct?

If client management is enabled, does CF _ever_ clean up client variables or
are they considered "permanent"?

If client management is enabled, is there a simple way, for testing
purposes,
to reset the client variables so that a developer can test an application as
if they were coming in fresh to the application? 
  _
 [Todays Threads] 
 [This Message] 
 [Subscription] 
 [Fast Unsubscribe] 
 [User Settings]

Re: Session vs. Client Management

2004-01-27 Thread Jim McAtee

- Original Message - 
From: "Philip Arnold" <[EMAIL PROTECTED]>
To: "CF-Talk" <[EMAIL PROTECTED]>
Sent: Tuesday, January 27, 2004 7:46 PM
Subject: RE: Session vs. Client Management

> This is from memroy, so some of it might be a little off
>
> > If a cfapplication has session, but not client management
> > enabled (and is using client cookies), then is there any
> > difference in the cookie that CF uses?  Expiration date,
> > for instance.
>
> The CFID and CFTOKEN variables are ALWAYS on the "session" level, so as
> soon as you close the browser, they go

Assume you're setting client cookies (which is necessary, if I'm not
mistaken, to track the session without explicitly passing around the
CFID/CFTOKEN url tokens). The bit of experimenting I've done today suggests
that closing the browser does not end the session.  It's picked up once again
from the CFID/CFTOKEN in the cookie as long as the session hasn't timed out
on the server.

> > How does CF keep track of sessions?  I realize it uses the
> > CFID/CFTOKEN combo set in a cookie or in the url, but where
> > does it keep session tracking information and session
> > variables?  In memory?  All sessions are lost if the cf
> > application service is restarted, correct?
>
> It's done with the CFID and CFTOKEN variables - when a new session is
> started (new browser window), it creates new ones for you
> >From the documentation:
> "Data is stored in memory so it is accessed quickly"
> "Data is lost when the client browser is inactive for a time-out period.
> You specify the time-out in the ColdFusion MX Administrator and
> Application.cfm."

It appears that a new session will be started, but since the cookie exists on
the client end, the session will have the same CFID/CFTOKEN.  This is why I
asked if "session-only" (if there is such a thing) cookies would have a
expiration vs. the cookies used when client-management is enabled.  For an
application only using session management, it doesn't really affect behavior
one way or the other, though.  I was just wondering.

> > If client management is enabled, does CF _ever_ clean up
> > client variables or are they considered "permanent"?
>
> In the Admin:
> "Purge data for clients that remain unvisited for [] days"

I'm running CF5 and don't see this in the Admin.  Was that included in this
version?

> > If client management is enabled, is there a simple way, for
> > testing purposes, to reset the client variables so that a
> > developer can test an application as if they were coming in
> > fresh to the application?
>
> There's a function
> DeleteClientVariable()

Ok, I can get rid of client variables in the client variable store, but I'd
really like to completely destroy the client cookies and force CF to see the
client with a completely new CFID/CFTOKEN.

Thanks.
 [Todays Threads] 
 [This Message] 
 [Subscription] 
 [Fast Unsubscribe] 
 [User Settings]

RE: Session vs. Client Management

2004-01-27 Thread Philip Arnold

This is from memroy, so some of it might be a little off

> If a cfapplication has session, but not client management 
> enabled (and is using client cookies), then is there any 
> difference in the cookie that CF uses?  Expiration date,
> for instance.

The CFID and CFTOKEN variables are ALWAYS on the "session" level, so as
soon as you close the browser, they go

> How does CF keep track of sessions?  I realize it uses the 
> CFID/CFTOKEN combo set in a cookie or in the url, but where 
> does it keep session tracking information and session 
> variables?  In memory?  All sessions are lost if the cf 
> application service is restarted, correct?

It's done with the CFID and CFTOKEN variables - when a new session is
started (new browser window), it creates new ones for you
>From the documentation: 
"Data is stored in memory so it is accessed quickly"
"Data is lost when the client browser is inactive for a time-out period.
You specify the time-out in the ColdFusion MX Administrator and
Application.cfm."

> If client management is enabled, does CF _ever_ clean up 
> client variables or are they considered "permanent"?

In the Admin:
"Purge data for clients that remain unvisited for [] days"

> If client management is enabled, is there a simple way, for 
> testing purposes, to reset the client variables so that a 
> developer can test an application as if they were coming in 
> fresh to the application?

There's a function
DeleteClientVariable()

HTH
 [Todays Threads] 
 [This Message] 
 [Subscription] 
 [Fast Unsubscribe] 
 [User Settings]

RE: Session vs. Client

2002-11-22 Thread Sandy Clark

Btw, I am also working on converting CF_Request to a CFC for MX.

Sandy Clark

-Original Message-
From: Doug Fentiman [mailto:[EMAIL PROTECTED]] 
Sent: Friday, November 22, 2002 5:36 PM
To: CF-Talk
Subject: Re: Session vs. Client

Sandy Clark and Michael Smith wrote an article about how to avoid
locking in
your code by the automatic conversion of client and session scopes to
request scope.

http://www.cfug-md.org/Articles/RequestVariables.cfm

 is a custom tag that converts Session or Client scoped
variables to Request scope.

Hope this helps,

DougF

 Original Message -
From: "Everett, Al" <[EMAIL PROTECTED]>
To: "CF-Talk" <[EMAIL PROTECTED]>
Sent: Thursday, November 21, 2002 10:10 AM
Subject: Resend: Session vs. Client

| I know the obvious issue with going from SESSION to CLIENT variables
(no
| complex data type in CLIENT) but is there anything else I should be
aware
| of? Does anyone have a write-up of methods they've used? For instance,
which
| is better: converting out current structures stored in SESSION to WDDX
| packets stored in CLIENT, or using simple ID fields in CLIENT and
running
| queries in Application.cfm and putting those queries in the REQUEST
scope?

~|
Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4
Subscription: 
http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
This list and all House of Fusion resources hosted by CFHosting.com. The place for 
dependable ColdFusion Hosting.

Re: Session vs. Client

2002-11-22 Thread Doug Fentiman

Sandy Clark and Michael Smith wrote an article about how to avoid locking in
your code by the automatic conversion of client and session scopes to
request scope.

http://www.cfug-md.org/Articles/RequestVariables.cfm

 is a custom tag that converts Session or Client scoped
variables to Request scope.

Hope this helps,

DougF

 Original Message -
From: "Everett, Al" <[EMAIL PROTECTED]>
To: "CF-Talk" <[EMAIL PROTECTED]>
Sent: Thursday, November 21, 2002 10:10 AM
Subject: Resend: Session vs. Client

| I know the obvious issue with going from SESSION to CLIENT variables (no
| complex data type in CLIENT) but is there anything else I should be aware
| of? Does anyone have a write-up of methods they've used? For instance,
which
| is better: converting out current structures stored in SESSION to WDDX
| packets stored in CLIENT, or using simple ID fields in CLIENT and running
| queries in Application.cfm and putting those queries in the REQUEST scope?

~|
Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4
Subscription: 
http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Structure your ColdFusion code with Fusebox. Get the official book at 
http://www.fusionauthority.com/bkinfo.cfm

57 matches

Mail list logo