Just curious.. how this might work.
Create HashMaps/Structs in the application scope for every unique hit
to the server and assign a unique cookie ID number for unique requests
and store session values in application scope.
if(Not structKeyExists(application.appUsers, '#uniqueID#')){
uniqueID = uniqueGeneratedID;
application.appUsers["#uniqueID#"] = structNew();
}
//then
application.appUsers["#uniqueID#"]['data'] =
createObject("Component","UserSessionData");
No Wddx Serializing/Deserializing involved with the above method and session
not used.
Thoughts on the above?
Thanks,
Joe Eugene
-----Original Message-----
From: Barney Boisvert [mailto:[EMAIL PROTECTED]
Sent: Friday, October 03, 2003 6:51 PM
To: CF-Talk
Subject: RE: RE: Session Variables Or Client Variables (Pros & Cons -
Poll)
I should give credit to John <someone> (either QvT or Farrar, I can't
remember which) for convincing me to write a custom system, rather than
use
native CF client variables. I was waffling at the extra work and
potential
execution costs, but he convinced me I'd be much happier down the road,
and
he was dead on. I guess it's kind of like the "don't use CFUPDATE"
epiphany
way back when.
barneyb
-----Original Message-----
From: Mike Brunt [mailto:[EMAIL PROTECTED]
Sent: Friday, October 03, 2003 3:15 PM
To: CF-Talk
Subject: RE: RE: Session Variables Or Client Variables (Pros & Cons -
Poll)
Very nice Barney!
Kind Regards - Mike Brunt
Original Message -----------------------
Yeah, custom DB, with a read in Application.cfm and a write in
OnRequestEnd.cfm. I use the 'clientvars' scope, since even if you turn
off
client variables, you still can't use the 'client' name. After th read,
any
complex data is unWDDXed for me automatically, and then reWDDXed before
the
write, so I don't have to think about anything if I want to store
complex
data. That will soon include the ability to serialize and deserialize
CFCs
as well.
I also have a field in my table for userID (separate from clientID), so
I
can acutally do a join between my clientrepository table and other
tables
in
the DB and pull up info like which user accounts are currently logged
on,
without having to actively record that information somewhere else. It's
quite handy.
I'm sure it's a little slower than the native CF client vars, but well
worth
it in my opinion. The queries take all of 2 or 3 milliseconds per
request,
and the WDDXing take another couple. I'm don't know how you'd test, but
not
much more overhead than what CF will do natively, and insignificant next
to
the typical page request time for the app (80-250 ms). The amount of
time
and money it saves with development and administration is very
noticable,
however. With one app, we just added a second CF server, and all we had
to
do was set up the load balancing, point the DSNs at the shared DB server
and
everything just worked. Plus, since it was running on CF Pro, we saved
$10,000 on not going to the J2EE version for session clustering. We'll
upgrade eventually, but we didn't have to right then, which was nice.
We
also can get around the CFC problem with session clustering, which is a
huge
advantage to me.
barneyb
-----Original Message-----
From: Joe Eugene [mailto:[EMAIL PROTECTED]
Sent: Friday, October 03, 2003 2:03 PM
To: CF-Talk
Subject: Re: Session Variables Or Client Variables (Pros & Cons -
Poll)
What custom system are we talking about? Custom DB with data write and
read with SQL for every request?
Are you by-passing CF Serialization/De-Serialization?
Matt.. mentioned something about using a local file system to do this.
Curious.. is this any effective than CF Client var?
Joe
----- Original Message -----
From: Barney Boisvert
To: CF-Talk
Sent: Friday, October 03, 2003 4:43 PM
Subject: RE: Session Variables Or Client Variables (Pros & Cons -
Poll)
I use a custom system, modelled on client variables. Everything is
stored
in a DB, but serialization and deserialization is automatic
(excepting
CFCs,
though that'll change). The biggest advantage is simple clustering,
becuase
you needn't worry about session replication, and you can also access
that
database for non-client variable stuff. THe data format is more
flexible,
so I can use application logic to control the tables as well as just
the
client mechanism.
Works very well.
-----Original Message-----
From: Joe Eugene [mailto:[EMAIL PROTECTED]
Sent: Friday, October 03, 2003 1:30 PM
To: CF-Talk
Subject: Session Variables Or Client Variables (Pros & Cons -
Poll)
Personally i am not a big fan of Client Variables due to DB
Serialize/De-Serialize Overhead
and not being able to store complex variables etc...
Just Curious..
What would be the CF Developer Consensus to using Client Variables
Or
using Session Variables?
Thanks,
Joe Eugene
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
