> > > The also recommend <name="#session.sessionid#"> when locking
> > > session vars; do you agree, or if not, what do you recommend?
> >
> > No, again, this causes the same problem. You want a unique
> > name to apply to an individual session, but you don't want to
> > store it in a session variable. If you're using CF's cookies
> > for state management, you could do this:
> >
> > <cflock name="#Cookie.CFID##Cookie.CFTOKEN#" ....>
>
> OK. I'm still having a hard time getting a grasp on this (so, what
> else is new?).
>
> I thought the whole idea of naming a lock was so nobody else would be
> able to read or write to that memory space and it would lock other
> users out based on the name of the lock.
>
> So, if I'm setting a session variable named "total":
>
> <cfset session.total = session.subtotal + tax>
>
> If I lock that cfset and name the lock #Cookie.CFID##Cookie.CFTOKEN#,
> won't that mean that anyone else would still be able to write to
> session.total and session.subtotal seeing as how using that method
> everyone would have the same lock named differently? I mean, why name
> a lock if every user has the lock named differently? Won't ColdFusion
> look and see if a lock by that name is being written and if it's not,
> go ahead and write it?
When you place a lock around something, you want that lock to have the
appropriate scope. Note that I'm not necessarily referring to the SCOPE
attribute here, although that does clearly describe the scope of the lock.
So, if you're locking session variables, and you're using 4.0.x so you don't
have the SCOPE attribute, you want your lock to allow only one request to
change those variables at any one time. Since sessions are unique to
individual users, you'll want your lock name to be unique to individual
users as well. You don't want to lock ALL session variables with an
individual lock, just the session variables which belong to that user.
> And a question about names across different application, or even the
> same application, but named differently:
>
> When accessing or writing an application or session variable, does
> the danger lie only within duplicate named variables within the same
> application? Or across the whole server? Example:
>
> I have 3 instances of my shopping cart on a server which uses the
> session variable "session.total", all 3 with the application name
> unique (I always name the application the same name as the main
> datasource of the app so there's no chance I can accidentally name 2
> applications the same). Joe Blow has his totally different shopping
> cart and it also uses a session variable of "session.total".
>
> If none of these were locked, and there is a single user using each
> shopping cart, and each cart has a diffent application name, and they
> are all writing a session.total at the exact same time, is there a
> danger in that? Or would there only be a danger if 2 people were
> writing to session.total in the SAME NAMED APPLICATION at the same
> time?
>
> If it's based upon the session variable name across the server and
> not within an application, then there's no way of knowing that you
> could ever have a uniquely named lock. I am HOPING it's based on the
> name in cfapplication.
In the case of session variables, it shouldn't matter which application
they're in, as long as each lock is scoped in such a way as to make it
unique to that individual user.
> And one more question:
>
> If you are locking all session variables with the same name by using
> a unique local variable, will that cause all writing to all sessions
> to be postponed until the lock is released?
>
> For instance, I have these 2 cfsets:
>
> <cflock name="#variables.mylock# type="Exclusive" timeout="10">
> <cfset session.total = session.subtotal + tax>
> </cflock>
>
> <cflock name="#variables.mylock# type="Exclusive" timeout="10">
> <cfset session.user_id = somequery.user_id>
> </cflock>
>
> Would the second query be locked out while the first is being written
> since the locks are named the same (even though they are accessing
> different session variables)? If so, then it seems like it would be
> detrimental to name any 2 locks the same that don't contain
> references to the same session variable. I'm assuming this is the
> case.
You're not really trying to lock an individual session variable; you're
trying to lock the Session scope. In any case, in the example above, the
second block of code won't execute until the first has completed anyway,
since a CF script is essentially a command batch.
Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
voice: (202) 797-5496
fax: (202) 797-5444
------------------------------------------------------------------------------
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
