I do the WDDX - structure thing cuz' I started out with loads of session
variables stored as structres, and arrays of structures. I needed to
retrofit db-client-var functionality to existing apps, so that's where the
WDDX-structure method came from. It would certainly be faster to not have to
use WDDX, but that'll only work if you have simple variables.
Alan McCollough
Web Programmer
Allaire Certified ColdFusion Developer
Alaska Native Medical Center
> -----Original Message-----
> From: Nat Papovich [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, August 31, 2000 9:42 AM
> To: '[EMAIL PROTECTED]'
> Subject: RE: Scope & Intranet Development
>
> I've just implemented client vars in a straightforward way - no
> structures,
> just getting them as I need. It's fast.
>
> A few months back, I made a post titled "OT: client vs. session speeds",
> dealing with this very issue. Here it is again.
>
> "I've run a good-sized test comparing speeds of the 2 scopes - client
> storage
> in a DB, no cookies used, URLToken passed.
> I came up with client vars being 11% faster. Since that goes against what
> seems to be common knowledge, I'd like to see some other results. Anyone
> else want to waste some time on this?"
>
> Keep in mind that my SQL Server holding the ClientDB was on the same box
> as
> the CFAS, which is not normally the case. Network traffic could
> potentially
> kill your application if you didn't set the DB and Web server next to each
> other.
>
> I'd like to see some more concrete test results, not theories and "As I
> understand it,..."
>
> NAT
>
> -----Original Message-----
> From: McCollough, Alan [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, August 31, 2000 9:06 AM
> To: '[EMAIL PROTECTED]'
> Subject: RE: Scope & Intranet Development
>
>
> Not necessarily. In my implementation of db client vars and fusebox, I get
> the db vars from the server at the top of the big "index.cfm" CFSWITCH,
> and
> write the vars to structures. At the end of a fuseaction, prior to going
> back to index.cfm, I write the vars back out to the db.
>
> So, I've got two basic trips to the db for vars on a given fuseaction.
> Once
> to load the vars into the CFAS, and once to write from the CFAS back to
> the
> db. It's been working great.
>
> Alan McCollough
> Web Programmer
> Allaire Certified ColdFusion Developer
> Alaska Native Medical Center
>
> > -----Original Message-----
> > From: Jeffrey Marsh [SMTP:[EMAIL PROTECTED]]
> > Sent: Thursday, August 31, 2000 6:17 AM
> > To: '[EMAIL PROTECTED]'
> > Subject: RE: Scope & Intranet Development
> >
> > What about client variables stored in a DB? In my application
> development,
> > I
> > try to get the database to do as much work as possible. I also try to
> make
> > as few calls to the database as I can. I try to make every call count.
> > With
> > client variables, aren't you hitting a database on every read and every
> > write of each little variable? What kind of performance issues are there
> > compared to session variables, which only use memory? I know Nat has an
> > opinion...
> >
> > --
> > Jeffrey B. Marsh
> > Amateurs built the Ark.
> > Professionals built the Titanic.
> >
> > -----Original Message-----
> > From: Michael Rahmn [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, August 30, 2000 9:02 AM
> > To: [EMAIL PROTECTED]
> > Subject: RE: Scope & Intranet Development
> >
> > Can someone expand a bit on how and in what template client vars are
> > set and called. Say for managing a var IsLoggedIn. I'm having a hard
> > time understanding the resource issue. It seems wrong to query the
> > database on every page (app_globals) to make sure they are still
> > logged in. Thanks
> >
> > PS This list has been a tremendous learning tool -- We've been able to
> > get our apps following the fusebox methodology except for the whole
> > state managment issue - still been using cookies for that.
> >
> > | -----Original Message-----
> > | From: McCollough, Alan [mailto:[EMAIL PROTECTED]]
> > | Sent: Tuesday, August 29, 2000 1:30 PM
> > | To: '[EMAIL PROTECTED]'
> > | Subject: RE: Scope & Intranet Development
> > |
> > |
> > | >From a development point, I find db-based client vars
> > | infintely easier to
> > | work with. Since all the vars are on a SQL server, I can
> > | query the server to
> > | see the state of all variables at any point in an
> > | application's flow. If
> > | you've got a 2nd development workstation at your desk, with
> > | some sort of SQL
> > | query tool, or even a CF page to check status, you can spy
> > | out client
> > | variables while an application is functioning; not just
> > | when it bombs out or
> > | is CFABORTed.
> > |
> > | Also, the occasionally irritating issue of unwanted
> > | persistance is cured for
> > | good. Want to delete a client variable? Issue a DELETE
> > | statement, and you
> > | know its gone.
> > |
> > | Alan McCollough
> > | Web Programmer
> > | Allaire Certified ColdFusion Developer
> > | Alaska Native Medical Center
> > |
> > | > -----Original Message-----
> > | > From: Ryan Wood [SMTP:[EMAIL PROTECTED]]
> > | > Sent: Tuesday, August 29, 2000 12:26 PM
> > | > To: '[EMAIL PROTECTED]'
> > | > Subject: Scope & Intranet Development
> > | >
> > | > I am a CF intranet developer and very frequently use the
> > | session scope.
> > | > Most
> > | > of the state management is by a local employee ID. It
> > | appears that most
> > | > people and examples on this list use the client scope
> > | rather than the
> > | > session scope. Other than load balancing, is there an
> > | advantage to there
> > | > any
> > | > to the client scope over the session scope when not using
> > | CFID & tokens to
> > | > track state/user management?
> > | >
> > | > Are there any other intranet developers who are using fusebox for
> > | > corporate
> > | > reporting & applications? If so, please email off-list
> > | ([EMAIL PROTECTED]).
> > | > I'd
> > | > be very curious to hear about your implementations.
> > | >
> > | > Ryan
> > | >
> > | > __
> > | > Ryan Wood
> > | > Intranet Web Developer
> > | > Corporate Systems-MIS
> > | > Datastream Systems, Inc.
> > | > 864.422.5260
> > | > 800.955-6775 x5260
> > | >
> > | ------------------------------------------------------------
> > | --------------
> > | > ----
> > | > To Unsubscribe visit
> > | >
> > http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebo
> > x or
> > > send a message to [EMAIL PROTECTED] with
> > 'unsubscribe' in
> > > the body.
> > ----------------------------------------------------------------------
> > --------
> > To Unsubscribe visit
> > http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebo
> > x or send a message to [EMAIL PROTECTED] with
> > 'unsubscribe' in the body.
> >
> >
> >
> --------------------------------------------------------------------------
> > --
> > --
> > To Unsubscribe visit
> > http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox
> or
> > send a message to [EMAIL PROTECTED] with 'unsubscribe'
> in
> > the body.
> >
> --------------------------------------------------------------------------
> > ----
> > To Unsubscribe visit
> > http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox
> or
> > send a message to [EMAIL PROTECTED] with 'unsubscribe'
> in
> > the body.
> --------------------------------------------------------------------------
> --
> --
> To Unsubscribe visit
> http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
> send a message to [EMAIL PROTECTED] with 'unsubscribe' in
> the body.
> --------------------------------------------------------------------------
> ----
> To Unsubscribe visit
> http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
> send a message to [EMAIL PROTECTED] with 'unsubscribe' in
> the body.
------------------------------------------------------------------------------
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
