Client Variables
We make use of Client variables throughout the application, storing
all simple variables such as Customer ID, Cart Totals, etc. as Client variables.
Some hosts may force you to use Cookies
for Client variable storage. In this case
cf_ezcart will not work if cookies are disabled in the shopper's browser. It must
also be set to collect credit cards AFTER the order has been placed IF your
secure SSL domain is not the same as your regular domain. If
your host uses Cookies as the default, and they will not set up a SQL
Server or MySQL database for storing your Client variables, or enable your
SQL Server or MySQL database as a Client
storage database (you really shouldn't use Access for this),
you should think about finding a new host. Unless, of
course, you don't mind losing the business of shoppers that have cookies turned off.
You should ask your current web host, or any host that you are considering
moving to, what their policy is concerning Client variable storage and what their
default storage method is. These are the likely answers, in order, MOST preferred first:
- Default is a database provided by the web host (SQL Server, MySQL or other
Client/Server database)... Great! You found a host that knows what they are doing!
This host will probably also give you the option of using your own SQL Server or MySQL database,
which may provide a little more security. If using your own, have the host set to purge client
variables after 1 day.
- Default is the registry or cookies but you may enable any of your databases or create a new
database... You shouldn't use an Access database if possible. If you're running on SQL Server or
MySQL, these will be ideal for client storage. After the database is enabled for Client storage,
enter Clientstorage="xxx", where xxx is the datsource name of the Client storage database.
- Default is the registry or cookies and these are the only options... This
should work. If cookies are the default,
enter Clientstorage="registry" to the cfapplication tag in Application.cfm. Keep in
mind that TOO many client variables in the registry and the registry will not accept
any more, bringing your web site down.
- Default is cookies and this is the only option... The shopping cart will work
for MOST people in this case, but we'd find a new host.
These are the pros and cons of using client variables vs. session variables (at least in our opinion,
and assuming a database for Client storage). If you are a developer, you may
have your own opinions.
Client Variables
- Pro: Allows cf_ezcart to be used in a "clustered" environment. A clustered
environment makes use of 2 or more servers, distributing traffic evenly among them.
This may cause a user that places an item in their basket to be directed
to another server on a subsequent click. If the items in the basket are stored
in a Session variable (in memory), or as a Client variable in the registry,
items will "mysteriously" disappear and reappear as the user moves from server
to server. Therfore, Client variables must be stored in a Client Storage
database that is accessible to all servers in the cluster. Most users of
cf_ezcart will not be running in a clustered environment, but it does help
make us Enterprise capable.
- Pro: If the ColdFusion application restarts or the server reboots, all
Session variables will be lost since the server's memory is cleared. Although
the site may be inaccesible for a minute or two during a CF restart or server
reboot, when it comes back up, the shopper's basket will be intact if you use
cf_ezcart.
- Con: May be a little slower, although generally not noticeably so, as ColdFusion must
read and write items to and from a database.
- Con: If you use your own database AND your site is very busy, AND
your host doesn't have autoshrink set on your database, the size of the
database may grow quickly. Mosts hosts will have a way to
"shrink" the database though or allow you to shrink your own if using your own.
Again, you should set client variables to purge after 1 day.
- Con: Complex variables (queries, arrays, etc.) must be "serialized" into a WDDX packet.
This is the main reason we moved our actual "shopping cart" into a regular database table and away from
client variables.
- Con: A database is a database, and therefore possibly accessible by others, making storage of sensitive
information more risky than storing that information in memory variables. For that reason, we do not store
any credit card information and the like using client variables.
Session Variables
- Pro: No need to worry about where Client variables are stored.
- Pro: Slightly (but usually not noticeably so) faster.
- Con: Using memory variables without proper locking may cause server instability. This was
especially the case back in the day of CF 4.0 and 4.5. And worse,
the correct locking code was different for each version. So when 4.5 came out, we had
to either re-write all of our code to accept both versions, or move to client variables.
We chose the latter.
- Con: All variables are lost during CF restart or server reboot.
- Con: Cannot be used in clustered enviroment without difficult steps being taken.