LiveDocs Comments - coldfusion - 6.1 - htmldocs - shared29.htm

coldfusion/6.1/htmldocs/shared29.htm

jrunrandy — 2005-02-08T12:15:37

Joe Simes,
I believe that you are correct. Sessions do not automatically end when the user closes their browser.

This is in our bugtracker as item 59746.

Randy Nielsen
ColdFusion Documentation Manager

coldfusion/6.1/htmldocs/shared29.htm

Joe Simes — 2005-02-08T10:06:53

I was wondering if this:

"The J2EE session automatically ends when the user closes all browser windows."

Means that a new session is spawned but the existing session still lives until timeout??

If I close my browser I see that my jsessionid changes on every return to the page but if I look at the "coldfusion.runtime.SessionTracker" I see that the previous session is still there.

To me this is no different than setting the cookies CFIF and CFTOKEN to expire on browser close.

Am I missing something?

Joe

coldfusion/6.1/htmldocs/shared29.htm

rdip — 2004-12-14T06:34:14

Won't J2EE session variables allow you to have multiple browser instances on the same client PC because each time you open the browser it gets a different jsession variable.

I know that ordinary coldfusion session variables are machine specific so the second browser instance will overwrite the session variables of the first browser instance.

Regards

Richard

coldfusion/6.1/htmldocs/shared29.htm

developerJon — 2004-11-23T07:26:50

I wish I could find more documentation about how to "support session failover among servers." I'm working on a project where there are a dozen servers and I want to use J2EE sessions. I'm assuming I have to set the load balanacer to use sticky sessions and I'm curious how I'll be able to persist the state information from any given sticky server to another server the server that a user was being directed to were to fail and the load balancer were to connect subsequent requests to another of the servers. How would the data stored in the J2EE session on the failed server become available on the next failover server??

coldfusion/6.1/htmldocs/shared29.htm

jrunrandy — 2004-08-25T06:25:31

The only disadvantage I can think of WRT J2EE session variables is that they might break things if you have an existing app that hard-wires variables, db column names, or db data to CFID and/or CFTOKEN.

coldfusion/6.1/htmldocs/shared29.htm

Not Nick — 2004-08-24T12:55:45

Docs mention the advantages with J2EE session variables, but it does not say anything about disadvantages or rather advantages with the "old" Cold Fusion session variables. Is the ANY reason NOT to use J2EE session variables?

coldfusion/6.1/htmldocs/shared29.htm

jrunrandy — 2004-07-29T12:29:22

Fair enough. I talked with one of the CF developers and he agrees with you.

coldfusion/6.1/htmldocs/shared29.htm

Steve — 2004-07-28T13:26:18

Maybe I'm missing something, but I don't see why that would matter with client variables. My understanding of client variables is they look for an application identifier (field: app) and a user identifier (fields: cfid/cftoken). Then based on that information it pulls the data from the database. So if you have multiple instances or multiple computers it's not going to matter.

coldfusion/6.1/htmldocs/shared29.htm

jrunrandy — 2004-07-27T05:24:54

I suppose the biggest thing is that you need J2EE session variables to use multiple CF instances deployed in a cluster of JRun servers.

Otherwise, if good old fashion client variables in a database are working for you, you probably don't need to change anything.

coldfusion/6.1/htmldocs/shared29.htm

Steve — 2004-07-26T11:35:29

What goal does this acheive that isn't possible with good old fashion client variables in a database?