jsessionid only exists if you are using J2EE session variables instead of
traditional coldfusion session variables (cfid and cftoken). So you have
either cfid/cftoken or you have jsessionid, depending on which type of
session variables you decide to use. To set which type you use, you go into
the CF Administrator in the session area (an option called "use j2ee session
variables" I believe) and when that is enabled, your session.sessionID will
be set to the jsessionid instead of the cfid/cftoken combo.
Hope that helps,
Judah
On Fri, Sep 19, 2008 at 10:20 AM, <[EMAIL PROTECTED]> wrote:
> All,
>
> The explanation below makes sense, but I'm tryiing to understand how do I
> grab and extract the jsessionid
> variable to I can prepend it to my session.cfid & session.cftoken in my URL
> session management.
> When I create a blank page within a directory that contains session
> management and try to outout
> the variable session.jsessionid, the variable won't part and I just get the
> variable name.
>
> <cfapplication name="id" sessionmanagement="yes" clientmanagement="yes"
> setclientcookies="yes">
> <cfset session.sessionID = session.cfid & session.cftoken>
>
> EXPLANATION
> If you have clustered JRun or ColdFusion running on JRun then you may have
> ran into an issue with sticky sessions. This little technical tidbit may
> help you out and you will better understand how JRun handles sticky
> sessions. Many people think that the connector handles sticky sessions with
> a table of current sessions. Well, it is much simpler than that and here is
> how it works.
> Sticky sessions hinge off of the jsessionid but not the entire id. When you
> create a JRun cluster the first time the server starts after it is added to
> a cluster a file called
> {cfusion}/servers/{servername}/SERVER-INF/connector.properties is created
> and the file contents look something like this:
> #Sat Nov 22 07:36:43 EST 2003
> server.id=c830
> The server.id is a 4 character string that is used to pre-pend on the
> front of every jsessionid that is created by that server. The connector has
> a listing of all server id's for all servers in a cluster and looks at the
> jsessionid and determines which server to route the request to. So a
> jsessionid created by the server with the id c830 will look something like
> this c830xxxxxxxxxxxxxxxx. By default sticky sessions are set to on even
> though the JRun documentation states otherwise. You can disable sticky
> sessions by modifying the jrun.xml with the following XML.
> <service class="jrun.servlet.jrpp.JRunProxyService" name="ProxyService">
> .............
> <attribute name="StickySessions">false</attribute>
> .............
> </service>
> You should really leave sticky sessions on unless you are not using the
> session scope at all. If you are using in-memory session replication you
> should leave sticky sessions on as well.
> If you run into a problem with sticky sessions the first thing to look at
> is the users jsessionid, make sure it has the first four characters of a
> valid server.id. If it does not all requests with that session id will be
> round robined across all servers in the JRun cluster.
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Adobe® ColdFusion® 8 software 8 is the most important and dramatic release to
date
Get the Free Trial
http://ad.doubleclick.net/clk;203748912;27390454;j
Archive:
http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:312842
Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm
Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4