Is there any reason not to share the same client storage
database between multiple ColdFusion servers?
We have 9 servers which all store their client variables in
the same database.
This is common for clustered servers. You'll probably want to enable
domain-specific cookies with the
In theory there shouldn't be any issues related to risks such as
variable pollution or user cross over.
The only concern I would have is making sure the client storage table
is maintained. If you don't manually (or through an automated task)
clean the table's old records out occasionally, it can
This is probably not a concern for you, because i'm assuming you own
and control all your servers, but in a shared environment, other site
owners will have access to your client variables with a simple query
on the table.
In a shared environment it's important to have your client vars stored
in
You can configure client variable storage ONLY at the CF server instance
level.However, it's amazingly trivial to create your own client variables
storage mechanims, which can store stuff wherever you want.And since
you're storing everything yourself, you can extend the functionality as
well, such
You can do one Client DB for 10 Applications with different application
names
Or
One Client DB per Application
However i would recommend using a SQL Server Scheduled Jobs to Purge Client
data.
Joe
- Original Message -
From: Tangorre, Michael [EMAIL PROTECTED]
To: CF-Talk [EMAIL
If I have 10 applications one one server and 10 DBs on one
sql server, is it possible to have each application handle
its own client variable tables?
Yes. You'll have to configure each datasource to store Client variables
within the CF Administrator, and you'll have to specify a
No kidding.
Learn something new every day.Not that I wouldn't still recommend
considering a custom setup, but that's good to know.
Cheers,
barneyb
-Original Message-
From: Dave Watts [mailto:[EMAIL PROTECTED]
Sent: Monday, July 19, 2004 1:58 PM
To: CF-Talk
Subject: RE: Client
Yes.You can set up each of the datasources as an acceptable client
variable repository in the cfadmin (what Barney said), then point to
that repository using the clientstorage parameter in your
Application.cfm's cfapplication statement.
Since my cms uses client vars extensively, I used to get
Thanks everyone. I am all set now. That was easy... :-)
Mike
[Todays Threads]
[This Message]
[Subscription]
[Fast Unsubscribe]
[User Settings]
[Donations and Support]
I suspect its been fixed in MX, what with the improved support for mySQL and all.
However the root cause of the problem was mySQL's failure to support subqueries, so
this may not be the case.
I CFSCHEDULE the template below, which I got way back when from the Allaire KB. Works
like a charm.
Well, the reboot actually worked - thanks for the suggestion.
Regards,
Howie
- Original Message -
From: Matt Robertson [EMAIL PROTECTED]
To: CF-Talk [EMAIL PROTECTED]
Sent: Sunday, November 18, 2001 10:23 PM
Subject: Re: Client storage woes
Have been following this thread all day
Cool. Get some sleep ;D
Cheers,
--Matt--
- Original Message -
From: Howie Hamlin [EMAIL PROTECTED]
To: CF-Talk [EMAIL PROTECTED]
Sent: Monday, November 19, 2001 12:22 AM
Subject: Re: Client storage woes
Well, the reboot actually worked - thanks for the suggestion.
Regards,
Howie
Ha - as soon as I get home :-)
Luckily, the office is only a mile from home...
Regards,
Howie
- Original Message -
From: Matt Robertson [EMAIL PROTECTED]
To: CF-Talk [EMAIL PROTECTED]
Sent: Monday, November 19, 2001 3:35 AM
Subject: Re: Client storage woes
Cool. Get some sleep ;D
On 11/18/01, Howie Hamlin penned:
1. Is the data schema exactly the same for both development and production
databases for the CDATA and CGLOBAL tables? Unless you created the data
schema manually, this shouldn't be a problem.
I had CF create the tables.
Maybe CF screwed up somehow when
caused the errorstrange...
Howie
- Original Message -
From: Bud [EMAIL PROTECTED]
To: CF-Talk [EMAIL PROTECTED]
Sent: Monday, November 19, 2001 8:27 AM
Subject: Re: Client storage woes
On 11/18/01, Howie Hamlin penned:
1. Is the data schema exactly the same for both development
Did you have ColdFusion create the tables on your production server when
switching to ODBC client storage, or did you import them from the dev box?
If you didn't have CF create the tables, it's possible you selected an
incorrect datatype.
Joseph DeVore
VeloxWeb Technologies
-Original
Our main web server has a registry that is huge because of
the CF client storage. So, I decide to store client data in
a SQL db. I can get this to work fine on my development server
but when I try to do the same thing for the production server
I get a SQL error when accessing pages:
I had CF create them.
Howie
- Original Message -
From: Joseph DeVore [EMAIL PROTECTED]
To: CF-Talk [EMAIL PROTECTED]
Sent: Sunday, November 18, 2001 5:41 PM
Subject: RE: Client storage woes
Did you have ColdFusion create the tables on your production server when
switching to ODBC
- Original Message -
From: Dave Watts [EMAIL PROTECTED]
To: CF-Talk [EMAIL PROTECTED]
Sent: Sunday, November 18, 2001 5:50 PM
Subject: RE: Client storage woes
Our main web server has a registry that is huge because of
the CF client storage. So, I decide to store client data
My production server has 2.5.1 and the dev server has 2.6. Would you recommend
upgrading to 2.6 or 2.7?
Thanks,
Howie
- Original Message -
From: Dave Watts [EMAIL PROTECTED]
To: CF-Talk [EMAIL PROTECTED]
Sent: Sunday, November 18, 2001 5:50 PM
Subject: RE: Client storage woes
My production server has 2.5.1 and the dev server has 2.6.
Would you recommend upgrading to 2.6 or 2.7?
I didn't even know there was a 2.7, so I'm probably not qualified to give
you advice on this. I'd probably stick with 2.6 SP1, since you know that
works on the dev server.
Dave Watts,
Compare the field types in your SQL Server databases on Dev and Production.
Your production database field type may need modified.
Tony Gruen
sfnetworks
-Original Message-
From: Howie Hamlin [mailto:[EMAIL PROTECTED]]
Sent: Sunday, November 18, 2001 1:54 PM
To: CF-Talk
Subject: Client
They are the same. I had CF create the tables...
Thanks,
Howie
- Original Message -
From: Tony Gruen [EMAIL PROTECTED]
To: CF-Talk [EMAIL PROTECTED]
Sent: Sunday, November 18, 2001 7:26 PM
Subject: RE: Client storage woes
Compare the field types in your SQL Server databases on Dev
, Inc. http://mysecretbase.com
-
- Original Message -
From: Howie Hamlin [EMAIL PROTECTED]
To: CF-Talk [EMAIL PROTECTED]
Sent: Sunday, November 18, 2001 5:53 PM
Subject: Re: Client storage woes
They are the same. I had CF create the tables
I haven't tried that yet but it's worth a shot.
Regards,
Howie
- Original Message -
From: Matt Robertson [EMAIL PROTECTED]
To: CF-Talk [EMAIL PROTECTED]
Sent: Sunday, November 18, 2001 10:23 PM
Subject: Re: Client storage woes
Have been following this thread all day long. Doesn't
i guess in all the 3 cases(registry, DB, cookies) there were would be 2
client cookies set (CFID, CFTOKEN) once we set "setclientcookies=yes" in our
application.cfm.
akbar
-Original Message-
From: Bill Killillay [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 17, 2000 7:16 PM
To:
://www.desertraven.com/
Make a fast friend, adopt a greyhound!
-Original Message-
From: Ed Toon [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 06, 2000 22:09
To: [EMAIL PROTECTED]
Subject: RE: Client storage (RE: ColdFusion 4.0.1/SPARC/Solaris help
sought - registry corruption and cf
If you're using client vars, get them into a database. If
you're not using them, make absolutely sure they're not enabled
anywhere.
I'd like to strongly second this recommendation. No one, under any
circumstances, should store client variables for an application within the
registry. The
This has nothing to do with client variables. Cold Fusion
uses the Registry a great deal itself internally. For example,
all datasource info, scheduled tasks, etc...
Most of this is done when the service starts up, and reads the data from the
Registry.
The Registry isn't designed to store
This has nothing to do with client variables. Cold Fusion uses the Registry
a great deal itself internally. For example, all datasource info, scheduled
tasks, etc...
--
Archives:
]
Subject: RE: Client storage (RE: ColdFusion 4.0.1/SPARC/Solaris help
sought - registry corruption and cf scheduler problems)
This has nothing to do with client variables. Cold Fusion uses the Registry
a great deal itself internally. For example, all datasource info, scheduled
tasks, etc
Well, yeah, using client variables in the registry certainly won't help, but
the point is that the registry on Solaris is fubar (we won't get into NT.)
I'm not saying everyone should start refreshing their registry every day...
I'm saying that it's not difficult at all to find yourself with a
Bud,
If you went through all of this trouble already, why not just get rid
of all session / client / application variables all together. I don't
really see the need for them. You can create your own database, and your
own clientID and password, and pass them along to each form This way
At 08:46 AM 8/19/00 -0400, you wrote:
Well. Due to my utter confusion over cflocks,
Thanks! I thot I was the only one ;-)
Does the following mean you let the database take care of locking
client variables and you don't bother CF with this little detail?
best, paul
I've gone in to my
On 8/19/00, Al Musella, DPM penned:
If you went through all of this trouble already, why not just get rid
of all session / client / application variables all together. I don't
really see the need for them. You can create your own database, and your
own clientID and password, and pass them along
On 8/19/00, paul smith penned:
Does the following mean you let the database take care of locking
client variables and you don't bother CF with this little detail?
Client variables are written to a database or the registry and
therefore are not susceptible to problems caused by multiple users
So as far as variables go (putting aside CFFILE considerations, and some
others mentioned by Forta such as CFX tags that aren't multithread safe and
CFHTTP) -- AND IF I have only:
APPLICATION scoped variables that once set are read only
VARIABLES scoped variables, and
CLIENT scoped variables
On 8/19/00, paul smith penned:
APPLICATION scoped variables that once set are read only
VARIABLES scoped variables, and
CLIENT scoped variables
and no other non-scoped variables,
then I don't have to worry about CF locking.
I believe the general consensus is you should still lock the
-Original Message-
From: Cameron Childress [SMTP:[EMAIL PROTECTED]]
Sent: Saturday, April 01, 2000 5:11 PM
To: [EMAIL PROTECTED]
Subject: RE: Client Storage: registry or database
however as I understand you can't rely upon client variables 100%
of the time. (Correct
Howdy all. Any pros/cons on way or the other about where to store
client variables?
The registry is not a good place to store Client variables, which are
relatively volatile data. The registry is designed for storing data that
will be read often, but written infrequently. If you use more space
: RE: Client Storage: registry or database
Howdy all. Any pros/cons on way or the other about where to store
client variables?
The registry is not a good place to store Client variables, which are
relatively volatile data. The registry is designed for storing data that
will be read often
, April 01, 2000 6:28 PM
To: [EMAIL PROTECTED]
Subject: RE: Client Storage: registry or database
On that same topic, I wanted to add that if you choose to store
those variables in a database, then you would be able to share
those variables across servers. This is something you can't do
42 matches
Mail list logo
