• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 283
  • Last Modified:

locking different session variables in the same session using named locks

Assume a session is created on user login,

<cfset session.UserAct = structureNew()>

this structure contains a number of arrays

<cfset session.UserAct.UserInfo = arrayNew(1)>
<cfset session.UserAct.UserPref = arrayNew(1)>
<cfset session.UserAct.UserOrder = arrayNew(1)>
<cfset session.UserAct.UserUpdate = arrayNew(1)>

Now all the above mentioned should be done in a lock, i.e.
<cftry>
<cflock type="Exclusive" scope="session" timeout="10">

<cfset session.UserAct = structureNew()>

<cfset session.UserAct.UserInfo = arrayNew(1)>
<cfset session.UserAct.UserPref = arrayNew(1)>
<cfset session.UserAct.UserOrder = arrayNew(1)>
<cfset session.UserAct.UserUpdate = arrayNew(1)>

<!--- Populate the session.userAct.UserInfo array from the database--->
<cfloop query="myquery">
<cfset session.UserAct.UserInfo[1] =Title>
.
.
.
.
.
.<cfset session.UserAct.UserInfo[i] =value>
</cfloop>

<!---populate the session.userAct.userPref from another query--->
<cfloop query="myquery1">
<cfset session.UserAct.UserPref[1] = color>
.
.
.
</cfloop>
</cflock>


so this is the typical situation where the whole session is locked for this duration.
Now if i want to lock different parts of the session variables, i should use names locking, so is the code written below correct
and it will only result in the locking of parts of the session variables (of course i will have to use these named locks every time
i want to access the specific session variable)? will there be any problems with the frist lock that is scoped?

<cftry>
<cflock type="Exclusive" name="session" timeout="10">
<cfset session.UserAct = structureNew()>
</cflock>

<cftry>
<cflock type="Exclusive" name="UserInfo" timeout="10">

<cfset session.UserAct.UserInfo = arrayNew(1)>

<!--- Populate the session.userAct.UserInfo array from the database--->
<cfloop query="myquery">
<cfset session.UserAct.UserInfo[1] =Title>
.
.
.
.
.
.<cfset session.UserAct.UserInfo[i] =value>
</cfloop>
</cflock>

<cftry>
<cflock type="Exclusive" name="UserPref" timeout="10">
<!---populate the session.userAct.userPref from another query--->
<cfloop query="myquery1">
<cfset session.UserAct.UserPref = arrayNew(1)>
<cfset session.UserAct.UserPref[1] = color>
.
.
.
</cfloop>
</cflock>

0
MMsabry
Asked:
MMsabry
  • 4
  • 2
1 Solution
 
mrichmonCommented:
No. this is wrong.

Name locking does NOT lock a portion of a session variable.  It simply locks a section of code so that two people can not be executing that code at the same time.

You need to still use session variable locks in your case.

So the session is not locked and in another page I could do :
<cflock type="Exclusive" scope="session" timeout="10">
<cfset session.UserAct.UserPref = arrayNew(1)>
<cfset session.UserAct.UserPref[1] = color>
</cflock>

and it would cause a problem even though you have in the other page :
<cflock type="Exclusive" name="UserPref" timeout="10">
...
</cflock>

These are two totally different things.

You need to use session locks every time you access a session variable.
0
 
MMsabryAuthor Commented:
I do not understand this answer! first of all the idea of locking the session variable is to lock the access to the variable itself so that it is not changed at any given time by two sets of Code. So as far as I understand, locking is used for both preventing the usage of the code "if you like", and more importantly access to the session variable.

I will put my question again in a different way

if the session variable is: session.UserAct.UserPref, and I lock this session variable in some process using a Named lock!
will the "Session.UserAct" and/or the "Session.UserAct.UserInfo" are still unlocked.

This is important to know since I use session variables in an insert query and i do not want the lock to time out if the query is slow for whatever reason. while at the same time i would like to allow other queries to use the rest of the information from the session to insert into other dbs
0
 
mrichmonCommented:
No locking does not lock access to a variable.

If you have some code that uses a lock and some that doesn't the variable can be accessed at the same time by both pieces of code.

Locking is a way of saying "For anyone else who cares I have a lock so you need to wait"

The only people that will wait are other portions of code that also have locking.

Therefore locking doesn't prevent two pieces from accesssing the same variables UNLESS they BOTH use the same locking.


This is the same with named locks.

A named lock (let's call it "LockA") says " I am locking this region of code which I am calling 'LockA'."  Now no one else trying to get LockA will be successful until ther first code releases it.  BUT if a section of code that does not use locks tries to execute the same code or access the same variables that the code with the lock does that second pice of code will be SUCCESSFUL.  Which is what you don't want.


Think of it this way.

Locking only works if everyone paraticipates.  It is kind of like taking a room and having a chalkboard on the door.  When you go in the room you write your name on the chalkboard and when you go out you erase your name.  Before you go in the room you are supposed to look at the chalkboard.  If there is a name on the chalkboard the room is occupied and you have to wait.  When the current person comes out and erases their name then you can write your name and go in.

Notice how this only works if everyone follows these rules.  If person C doesn't even check the chalkboard before going into the room then person C doesn't know whether or not the room was already occupied.

Also if person D goes in the room through a side door or a window - they didn't even see the chalkboard.

Locking is the same way.  It only works if all of the code uses the same locks - but there is no actual security on the thing being "locked"

I hope this helps.
0
Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

 
mrichmonCommented:
The best solution for an insert that uses session variables is something like this :

<cflock scope="session" timeout="10">
<cfset tempname = Sesssion.profname>
<cfset tempclass = Session.Class>
<cfset tempDate = Session.ClassDate>
etc...
</cflock>

<cfquery datasource="mydsn">
INSERT INTO mytable (ProffesorName, ClassID, ClassDate) VALUES ('#tempname#', #tempclass#, #tempDate#)
</cfquery>


SO basically you only use the lock to quickly write the values to temporary local variables and then you release the lock.

Then you do the insert using the local variables so that others can use the "locked" variables even if the insert goes slowly since the isnert is using COPIES of the "locked" variables and not the actual session variables.
0
 
mrichmonCommented:
One more comment.

You mentioned

 "if the session variable is: session.UserAct.UserPref, and I lock this session variable in some process using a Named lock!
will the "Session.UserAct" and/or the "Session.UserAct.UserInfo" are still unlocked."

I just wanted to clarify that a named lock does not prevent access to a variable of the same name.  BUT, if everytime you used that variable you used the named lock then it would make "everyone" participate in the locking procedures and would work.

But realize that " everytime you used that variable" INCLUDES access to just the session itself.  Because if I had code that cleared the session - it would have to be locked using the named lock of that individual variable too - since that variable is part of the session.

I know this is kind of confusing, but really the best way to lock is this :

Any time you access a variable in a shared scope (i.e. a Session variable) used the SCOPE lock associated with the scope.

If you want to lock something else (like access to a specific file) then use a named lock where the name is based on the resource being lock (note that it is NOT in a shared scope).

Hope that helps a little
0
 
MMsabryAuthor Commented:
mrichmon,
thanks for the detailed expl.
I think I will follow this method
thanks once more
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

  • 4
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now