how to implement session binding

Hi Vasu,

 

 

Session binding in the F5 world is called persistence. You can read in the LTM config guide on AskF5.com for details on the various persistence options. One of the simplest, most effective persistence options is cookie insert persistence. It has low overhead because LTM doesn't store the persistence record in its memory. It's specific to the browser instance's session. And it generally "just works".

 

 

If you have a Java based app and want to persist the client to the same pool member using the jsessionid in the URL or cookie, you could use an iRule:

 

 

Weblogic_JSessionID_Persistence - Provides persistence on the jsessionid value found in either the URI or a cookie. (Click here)

 

 

Aaron

Thank you very much!

 

 

The java application server is Oralce Application Server 10.1.3 (OC4J) not weblogic server.

 

Application teams wants persist the client to the same pool member.

 

 

Do you have handy IRule for implementing jessionid ?

 

 

I think the concept if not the exact implementation would be the same. Is the jsession ID included in a cookie or the URI? If the URI, is it in the format of /path/to/file.ext;jsessionid=something?query_string_param=value ?

 

 

Aaron

I am trying something like this , not sure this will works.

 

 

Jsessionid_rule

 

 

when CLIENT_ACCEPTED {

 

set add_persist 1

 

}

 

when HTTP_RESPONSE {

 

if { [HTTP::cookie exists "JESSIONID"] and $add_persist } {

 

persist add uie [HTTP::cookie "JESSIONID"]

 

set add_persist 0

 

}

 

}

 

when HTTP_REQUEST {

 

if {[HTTP::cookie exists "JESSIONID"]} {

 

persist uie [HTTP::cookie "JESSIONID"]

 

}

 

else {

 

set jsess [findstr [HTTP::uri] jessionid 11 ";"]

 

if { $jsess != "" } {

 

persist uie $jsess

 

}

 

}

 

}

 

 

 

That's basically the same solution as the Codeshare example. The downside of that rule is that if multiple different clients make requests over the same TCP connection with different jsessionid's only the first client would have a persistence record added in the response. That could be considered a problem. I'd suggest using the Codeshare example as it's fairly well tested by a few people.

 

 

Aaron