Forum Discussion
vasu_95875
Nimbostratus
Nimbostratushow to implement session binding
How many ways we can implemement session binding using F5 LTM ?
Java Developer said he wants session binding with JSESSIONID.
1. Do I need to create a IRule to implement session binding ?
2. Can this be achived with cookie persistence profile?
Thanks in advance .
Vasu
hoolioCirrostratus
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
vasu_95875Thank 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 ?- hoolioI 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 - vasu_95875I 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
}
}
} - hoolioThat'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