On 11/23/05, dsmith @ psea. org dsmith @ psea. org <[EMAIL PROTECTED]> wrote: > Nathan, > You raise some good points. In your opinion if I'm not running in a > clustered environment, are session variables the way to go? Anyone else have > thoughts? >
The answer is very dependent upon details of the application -- session uses memory on the server, client involves an additional database hit. Right answer depends on the load on the application -- but for a smaller app, it shouldn't be a big deal for either. Default CFMX session behavior blows up if you have cookies disabled as well -- J2EE sessions can help with that. As an aside, one enormous difference between client and session is that you can't store any complex data types -- no structures, arrays, etc -- only text (which in CF includes numbers, dates, etc). The *fix* for that is to use WDDX to read/write your structs/arrays/etc to text and store that in client scope, though that adds even more overhead. While this sounds like it's pushing you towards session, it doesn't have to be quite so black-and-white. I built an app two years ago for a company that wanted to be able to scale quickly without buying CF enterprise -- so the mandate was to use client-scoped variables. The app has a *lot* of structures/arrays that needed to be persistent, so that's lots of WDDX data (including the entire shopping cart which generally has 30-50 items in it) and a lot of transfer back/forth to the database. On every hit. Knowing that at some point moving to session was almost a given, I did some simple information-hiding so that the code doesn't know anything about session/client scope for persistent variables -- at the beginning of each request (Application.cfm, though in FB4.1 I used a global prefuseaction) I pulled all the data out of the persistent store (client scope wddx data in this instance) and copied it to variables scope (though you could probably use request if you wished). Once all of the processing was done, I wrote the data back to the persistent store at the end (OnRequestEnd.cfm, though I used FB4.1's global postfuseaction instead). What this meant was that if we moved from client to session, the application doesn't know anything changed. I could change the process to pull the data from multiple places (some in session, some in client, some pulled out of the db directly) as long as the resulting output all went into variables scope. Did I add overhead -- sure, a minor bit (esp compared to WDDXing a lot of data and pushing it to client scope) but the app is much more maitainable and flexible. Turns out the application still runs on a single vanilla dell server -- it never hit the massive load they thought, though it still runs 50k-100k of business/week. And it still handles the persistent data in client scope, though changing it to session would require tweaking code in precisely two places. My real point is that a clean app design can let you switch between the scopes as appropriate (heck, global search/replace from client. to session. would probably work as well). It's not bad to think about the design up front, but it's not hard to handle changes gracefully either. -- John Paul Ashenfelter CTO/Transitionpoint (blog) http://www.ashenfelter.com (email) [EMAIL PROTECTED] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225081 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=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
