use of session variable in multiple pages in coldfusion


I have a form where I am currently displaying html code that the user can type in and update, as well as a link to the original file (where the base html source code came from).  I want to be able to create a preview button that will render the new code in the form before they save.   I thought I could use a session variable to hold the form data, but do not understand how I would I guess pass, or use this on the second page displaying the new generated file.  
I've been using <cfset #session.tempInfo# = form.File />
and then set up an onclick=popup.cfm?....and I think this is where I would add a variable.
Who is Participating?

Improve company productivity with a Business Account.Sign Up

gdemariaConnect With a Mentor Commented:
@BSSupport, I have often looked for information on the web to support your view.  I have not been able to find much, at least not by any authority such as Adobe or Ben Forta.  I would very much like to see evidence as I would like to alter my view and reduce using CFLOCK, so please provide a reference if you are able.

You are correct that MX 7 greatly reduced the need for cflock (you skipped CF 6), but here are excerpts from the current adobe documentation for Coldfusion 8...   The last block is the only information I have found about not using cflock and it is pretty limited in scope.

Locking memory variables
Because ColdFusion is a multithreaded system in which multiple requests can  share Session, Application, and Server scope variables, it is possible for two  or more requests to try to access and modify data at the same time. ColdFusion  runs in a J2EE environment, which prevents simultaneous data access, so multiple  requests do not cause severe system errors. However, such requests can result in  inconsistent data values, particularly when a page might change more than one  variable. To prevent data errors with session, application, and server variables, lock  code that writes and reads data in these scopes. For more information, see Locking code with cflock.


ColdFusion persistent  variable issues
  • Variables in the Session, Application, and Server scopes are kept in  ColdFusion server memory. This storage method has several implications: All variables in these scopes are lost if the server stops running.  
  • Variables in these scopes are not shared by servers in a cluster.  
  • To prevent race conditions and ensure data consistency, lock access to all  code that changes variables in these scopes or reads variables in these scopes  with values that can change.

Using the cflock tag with write-once variables You do not need to use cflock when you read a variable or call a  user-defined function name in the Session, Application, or Server scope if it is  set in only one place in the application, and is only read (or called,  for a UDF) everywhere else. Such data is called write-once. If you set an  Application or Session scope variable in Application.cfm and never set it on any  other pages, you must lock the code that sets the variable, but do not have to  lock code on other pages that reads the variable's value. If you set the  variable in the corresponding start method in Application.cfc (for example,  onApplicationStart for Application scope variables), you do not  have to lock the code that sets the variable.
However, although leaving code that uses write-once data unlocked can improve  application performance, it also has risks. You must ensure that the variables  are truly written only once. For example, you must ensure that the variable is  not rewritten if the user refreshes the browser or clicks a back button. Also,  it can be difficult to ensure that you, or future developers, do not later set  the variable in more than one place in the application.

Why not just submit the form to a new page using taget="_blank" in the <form> tag.

Then you can just use the form variables and never leave your page.

 (I am not a proponent of using session variables all the time)
not 100% sure what you want, but this may work for you...

on page(2) of the form, use:

<cfset session.form=StructNew()>
<cfset structappend(session.form,form,true)>

this will basically, dump the form into a session level structure. Then do whatever you want, just remember that instead of referencing #form.field# or #form["field"]# , you would just reference #session.form.field# or #session.form[field]# ...

just remember to delete the session structure afterwards.
<cfset structDelete(session,"form",false)>
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.

If you go the way of the session variable (not recommended) don't forget to CFLOCK them
tiredntroubledAuthor Commented:
okay, so if I have <cfset #session.tempInfo# = form.File /> on the page with the form, the user clicks on a button and then in the page which is a popup I would have what you put albrandwood, <cfset session.form=StructNew()>
<cfset structappend(session.form,form,true)>
and this would allow me to use what is stored in the form field, correct?
First you have to get the value of the form field.  
If the user is entering information into a field you have called "file" as in ...

<input type="text" name="file" value="">

You need to click *submit* the form get the value to coldfusion.  So you would do the session assignment inside the action page of the form.   It's on the form's action page, the variable form.file will now exist and be populated with the value the user entered.

On the action page, you can use the form's fields...
<cfset session.tempInfo = form.file>

or to copy all of the fields from the form, you can do the entire structure...

<cfset session.allFields = structCopy(form)>

(Of course you know you have to use CFLOCK anytime you write to a session variable, not shown)

Now you have the session.tempInfo holding the one field;s value
or session.allFields as a structure holding all the forms field values.

When you draw the next page, you can then use this session variable in the page or pop up another page from there.   To use the session variable simply assign it into anything else you want, another variable or form..

Of course, it's much easier to simply submit your form to a new window (the popup) and use the form variables in the pop-up directly...

<form action="myPopup.cfm"  target="_blank">

And in the myPopup.cfm file, simply refer to the variables..


Locking session variables hasn't been absolutely necessary since CF5. It's now only necessary if a race condition is possible, which is unlikely with session variables. It's only likely if framesets or multiple simultaneous Ajax requests are involved for a single client.
It's right there in the info you posted. Multiple, simultaneous requests are the only way to get race conditions and with session variables they are only likely via frames or multiple AJAX requests. How else do you get multiple access to the same session variables?
Also in the information I posted it clearly says ..

" if it is  set in only one place in the application, and is only read (or called,  for a UDF) everywhere else "

 "You must ensure that the variables  are truly written only once."

>  How else do you get multiple access to the same session variables?

according to this documentation, it appears that a form submit or click the back button would

" For example, you must ensure that the variable is  not rewritten if the user refreshes the browser or clicks a back button  "

 Updating session variables on form post (as the asker is doing) clearly falls into this category and according to this information, needs to be locked.

 I am very interested in hearing contradictory evidence as I would like to alter my coding methods, but to me this is pretty clearly in favor of locking  unless for read-only variables.

Never mind, you don't understand race conditions.
Lol, I'm just quoting the documentation written by Adobe.   It seems you are the one unable to keep up.
Excellent!   That's a very good page from Ben Forta.    It is in line with the adobe documentation that I showed, but it gives a bit more detail and clarifies the situations in which a single session can induce race conditions...

Forta agrees with your perspective that it is less likely, but he also clearly states that it is "quite possible."    The way a single session can create race conditions would be to submit a form multiple times or use the back button - this is the same information included above by Adobe documentation, but a bit clearer here.  Therefore, if your form post is going to write to the sesssion, as tiredntroubled is doing, then you should cflock your session variables.    Granted it is unlikely to happen, but still "quite possible."

Quoting the book:

In general, it's much less likely that race conditions will occur at the session level than at the application application level, as there is usually only one page request coming from each session at any given time.  Even though it's unlikely in the grand scheme of things, it is still quite possible that more than one request could be processed from a session at the same time.Here are examples:
.. skipped frame example..
If for whatever reason (perhaps network congestion or a heavy load on your Coldfusion server) a particular page is taking a long time to come up, many users tend to click their browser's reload or refresh button a few times.  Or they might submit a form multiple times.  In either case, it's quote possible that a second or third request might get to the server before the first request does.

And to quote me:

"It's now only necessary if a race condition is possible, which is unlikely with session variables. It's only likely if framesets or multiple simultaneous Ajax requests are involved for a single client."

Which says EXACTLY the same thing. It's unlikely, but possible.
> It's only likely if framesets or multiple simultaneous Ajax requests are involved for a single client ...

OR if the user clicks the back button or clicks submit multiple times....

So we have reached a conclusion...

   It's a matter of risk tolerance..

Nice debating with you.  
We have covered this topic well, perhaps we should make an article out of it.

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.

All Courses

From novice to tech pro — start learning today.