> > > Try to set your session vars in the login script like this
> > >
> > > <cflock name="login_info" timeout="900" throwontimeout = "yes"
> > > type="readonly">
> > >   <cfset session.fname = "users fullname">
> > > </cflock>
> >
> > I think it's important to point out that this example will
> > only work if every other use of session variables within this
> > application is locked with the name "login_info"!
>
> Correct me if I'm wrong, however, Lock names are global across a
> server.  They are not limited to the specific application.  I'm
> actually unclear what constitutes a server in this case.  (a domain?
> a physical machine?)  Although domains only have one application
> within them, that is not always the case.

Lock names are global across a server. However, just putting a single CFLOCK
tag around one instance of something doesn't, by itself, lock anything.
That's the crucial point I wanted to get across. CFLOCK is a cooperative
mechanism. When you use CFLOCK, that's a signal to the server not to allow
other things that identify themselves as the same lock to execute. So, if
these two code snippets are executed at the same time by the same user's
session:

<!--- page1.cfm --->
<cflock name="lock1" ...>
        <cfset session.foo = "bar">
</cflock>

<!--- page2.cfm --->
<cflock name="lock2" ...>
        <cfset session.foo = "baz">
</cflock>

neither lock will do anything - the first one will look to see if there are
any other active locks named "lock1", find that there aren't, then do its
stuff. The second one, likewise, will look for any active locks named
"lock2", find none, and execute the CFSET.

> And just to clarify (and make sure that I understand), the reason
> I couldn't use code like this:
>
>  <cflock name="login_info2" timeout="900" throwontimeout = "yes"
>  type="readonly">
>    <cfset session.othersesionvariable = "value">
>  </cflock>
>
> Is because, a 'session' is a structure, and a structure is only one
> variable, and both different lock 'names' are going after the
> same variable.  Correct?

There are a couple of problems with that code sample.

First, if you're using CF 4.5.1, you should use the SCOPE attribute to
identify the lock, rather than the NAME attribute. Second, if you're
changing something within the Session scope, you'd want your lock to be
TYPE="EXCLUSIVE", rather than readonly. Third, if you did stick with the
NAME attribute, you'd need to make sure that any other code manipulating or
reading session variables used the same value within its NAME attribute.

I hope you find this helpful!

Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
voice: (202) 797-5496
fax: (202) 797-5444

------------------------------------------------------------------------------
To unsubscribe, send a message to [EMAIL PROTECTED] with 
'unsubscribe' in the body or visit the list page at www.houseoffusion.com

Reply via email to