Double JSESSIONID Values Being Set
If you're using the Enterprise version of ColdFusion MX, you have the option of using the J2EE session variable mechanism rather than the built-in ColdFusion session variable mechanism. If you're not familiar with the difference, read this page in the LiveDocs to understand each option. I'll still be here when you get back -- don't worry.
Now that we're all back, the JSESSIONID is critical to ColdFusion being able to "look up" your stored session structure on each page request. And since I need to be able to replicate sessions in a cluster, which only J2EE session variables support, this is a must-use feature for me. However, when using the internal JRun web server (which you should only use for development), when you request your site's root (i.e., http://www.mysite.com/, ColdFusion wrongly sets two JSESSIONID values, which can cause it to "lose" your session scope on subsequent requests. Here is an example HTTP header that is set on an initial page request to a site root:
See the bug? There is a double Set-Cookie directive that sets not one, but two JSESSIONID values, effectively creating two sessions on your server for every one. This has a nasty side-effect in that more server resources are taken up per user because they technically have two sessions for every one, even though only one is actually used after the initial request. Interestingly, if I were to manually add the index.cfm page to the URL request, i.e., http://www.mysite.com/index.cfm, only one JSESSIONID value is set. So the bug occurs when requesting your site's root document without explicitly typing the desired CFM template. (And yes, if you note the Date value, you'll see just how long I've been trying to figure these bugs out!) Lastly, I should note that when I did a test in my MX 6.1 instance, the same bug exists there. So this isn't exclusive to CFMX 7.
Old DataDirect Drivers Ship with MX 7.0.2, Breaking Client Variable Updates
In my opinion, this bug (and yes, it's a bug) is the much bigger one of the two because this is one that will find its way out to a production environment if you're not aware of it, and has nothing to do with the web server being used. A long story short, Adobe ships the DataDirect 3.3 driver set in the 7.0.2 bits (released on 6/28 of this year), even though the 3.5 driver set was released as a TechNote last October. So much for the point releases being cumulative updates!
You might be wondering why this is such a big deal to me. Well, there are two reasons. First, we use Oracle 10g Release 2, which only the DataDirect 3.5 driver set supports. Second, it turns out that client variable records (in the CDATA and CGLOBAL tables) were not being updated, which meant that once you logged in to our web site (where a few client variables are set) and then clicked to a subsequent page, it would appear as if you had never logged in. The initial insert of the record was working fine (which you can see in the HTTP header sample I pasted above -- it's the CFID/CFTOKEN value), but any updates to the record would silently fail (I say "silently" because ColdFusion handles this for you under the hood, and it doesn't log anything when problems occur). I was going absolutely nuts trying to figure out why it wouldn't update, and the Spy feature of the JDBC drivers (described at the bottom of the aforementioned TechNote) simply wasn't working. After thinking and thinking and thinking, it belatedly occurred to me that the Spy features were only baked in to the 3.5 driver set. So, on a hunch, I ran the CF script below between my MX 6.1 instance (which was working perfectly fine) and the MX 7.0.2 instance to check the driver versions. (Note: The output is written to your log file, so your screen will be blank.)
The MX 6.1 results:
and the MX 7.0.2 results:
After seeing this, I swapped out the old 3.3.48 driver set with the 3.5.13 driver set and everything has been working without issue since.
If anybody on the Adobe ColdFusion team happens to read this, the installer bits need to be updated with the 3.5 driver set. If it passed your regression tests such that it was officially released as a TechNote, then all subsequent "cumulative" updaters and downloadable installers should contain the updated drivers. Further, the fact that the 3.3 drivers ship with MX 7.0.2 means that your System Requirements page is wrong because the 3.3 drivers do not work with Oracle 10g Release 2. Also, please don't call something "cumulative" if it is, in fact, not cumulative. Since I was under the impression that the Updaters were cumulative, it obviously wasn't my first thought to check the JDBC driver version for a regression. Now I need to go back and look at the web connector versions and other items to make sure that those were properly baked in to the latest release. Lastly, If you're not going to update the drivers, then you have to clearly state this in the Release Notes, as there was no mention of this whatsoever.
Anyway, I hope my two weeks of pure frustration helps somebody solve any related setup issues they might be having. Incidentally, my set is ColdFusion MX 7.0.2 on Red Hat Enterprise Linux 4.0 (SELinux turned off) using the internal JRun web server. The above bugs appear in my environment and I do not have a means of testing others. If you'd like to try and confirm these issues in other environments, go ahead and comment back here what you find.
Once last shout out to Jochem van Dieten for sticking with me on my forum thread on this subject. It was very much appreciated.
cflocation url="somewhere.cfm?#mysessiontoken#"
(leaving off the addtoken param) that CF would assume addtoken=yes and double up the session tokens.
The fix was to either remove the #mySessiontoken# var from the url param or add adtoken="no"
Could this be what you are seeing?
Any workaround will be very appreciated. I was burning my head trying to understand why my sessions are lost so frequently under this cluster.
Thanks!
Sorry for the confusion.
The Sys requirements page does indeed show Oracle 9 R2 supported, but only with "Oracle 9 functionality", which means we ran the 3.3 driver regressions against that version of Oracle and all regressions passed.
Now, we also have made available the TechNote that has the latest 3.4 and 3.5 (I believe) DD driver downloads for CF customers, but there have been problems like hangs and stability issues with some of these driver versions, and regression problems for things like CLOBS and BLOBS for Oracle and issues, so unfortunately it's a matter of picking the right version for your needs at the moment. The 3.3 driver version we shipped in 7.0.2 was the safeest version for customers in general, and that's why it's in there.
The 3.4 and 3.5 versions have been getting better as customers report issues and we work with DD to correct, and they give us new drops, and we post them with their known issues, but I refuse to make the same mistake I did in CFMX 6.1, where I trusted that the newest driver set was stable on a 3rd party's word. We're moving towards "trust but verify", with a full closedown cycle.
For the next major release, we have a fiull closedown cycle available to find the hairy issues, so we're likely going to go to the very latest, and make use of all the latest API's, etc, since we have time to find any issues.
Hope that clarifies the deal on DD drivers in CF.
WRT the dup-jsession issue, let me look into the status of this one....
HTH
Damon
Anyway, that being said, there should be a note in the Release Notes that the 3.3 drivers are what ships with 7.0.2, and provide a link for the 3.5 driver set TechNote for those who are using Oracle 10g R2 (which is an increasing number since it's been out for over a year now) or are experiencing other database-related drivers. Ironically, you note that you ship the 3.3 drivers due to customer issues, but I need the 3.5 drivers in order to use ColdFusion.
Thanks again for your time.
I'm not sure what was happening in your case, but all regressions definitely pass with the 3.3 drivers. These are the same drivers we shipped with CF MX 7.0 and if your statement were true, thousands of developers/customers would have complained of broken functionality, but that's clearly not the case.
I'll ask Engineering Escalation to take a look into your issues further and see if we can figure out what the deal is.
Sorry for the frustration, and yeah, we should have release-noted the fact we shipped the 3.3 driver set with 7.0.2, for sure. Sorry about that.
Damon
<cfif not isdefined("cookie.jsessionid")>
<cflocation url="#cgi.SCRIPT_NAME##cgi.QUERY_STRING#">
</cfif>
For testing
<cfdump var="#cookie#">
i have one application with coldfusion version 6, now i have to migrate entire code to 7 what are the changes i need to make, and i am changing the server from windows to unix,if any one knows please tell me.