jbo.dofailover=true, PS_TXN and Browser Cookie Limit

An interesting post by Steve Muench, regarding all the above. It's a bit old (November 2004) and something might change since then but nevertheless it worth reading. Reposting below:

A Tale of Twenty Cookies (And No More!)

This week one of our worldwide support engineers was working with a customer experiencing a problem of having their HTTP session sporadically get dropped in their ADF-based application. The problem only occurred when users would use the Internet Explorer browser; it didn't reproduce with Firefox, for example, however the customer's userbase are IE users, so switching to Firefox wasn't an option as a workaround.

The support engineer did some testing to discover that Internet Explorer strictly adheres to the RFC2109 specification's limit of 20 cookies per domain. I worked with him to build an example servlet which accessed the J2EE web container's servlet session, and then proceeded to add a cookie with a unique name on each time the page would get refreshed...Cookie1, Cookie2, Cookie3, etc. After refreshing the page 19 times using the Internet Explorer browser, we could see we had twenty cookies like this:

JSESSIONID=...
Cookie1=...
Cookie2=...
    :
  etc.
    :
Cookie19=...

Of course, the JSESSIONID is the cookie used by the web container to keep your browser session "connected" to the server-side servlet session object over the stateless HTTP protocol. If you lose the JSESSIONID cookie, then to the server, the next time you visit it's as if it was your first time again. Refreshing the page one more time with our test servlet, showed that Internet Explorer -- having hit its limit of 20 cookies -- picked the least recently set cookie and got rid of it to make room for the new Cookie20 we created. It turns out that the least recently set cookie was the very JSESSIONID cookie that was our lifeline to the servlet session. Ouch! With Firefox, it appeared that fifty cookies was the limit in our testing, while other browers like Opera had yet another limit like 30. But in IE, this effect occurred at the RFC2109 20 cookie limit.

The support engineer asked the customer whether the own application was creating lots of cookies, but the response was that they weren't creating any cookies themselves. Then he asked them how many distinct ADF application modules their JSP pages were using, and the answer was "about 25". Next he asked them if they were using the ADF Business Components failover mode. They didn't remember having set it, so they were using the default which is jbo.dofailover=true. That is, the failover mode is on by default unless you disabled it in your application module configuration or by supplying a Java System parameter named jbo.dofailover=false at system startup time.

So, the support engineer had found the problem. Each ADF data control that is based on an ADF application module and which is being used in failover mode, saves a browser cookie that contains the persistent snapshot ID of the pending application module transaction state (which by default is saved in the database in a BLOB in the PS_TXN table, with that persistent snapshot id as its primary key. If you use 25 unique application module-based data controls in your application and you leave the failover mode on, you'll need to save 25 browser-side cookies to provide that failover support. If the middle-tier application server you were using goes down, on your next request, whatever server you do end up getting serviced by uses the value of the persistent snapshot id in the browser failover cookie for each data control to rendezvous with the right persistently stored pending changes.

Trouble is, if you need 25 cookies plus the JSESSIONID which makes 26, then at some point you'll hit your 20-cookie limit in Internet Explorer, and there's a chance that IE will throw out your JSESSION cookie, which cuts off your browser user's lifeline to the session. That in an of itself wouldn't cause trouble for ADF, but in this customer's case, they had placed a user login object of their own creation in the session, so it was no longer there once Internet Explorer had forgotten its JSESSIONID cookie.

The solution? The customer didn't actually need the failover feature, so they added the -Djbo.dofailover=false Java VM parameter to their application server startup to disable the ADF failover mode, and the problem has gone away.

One tip to help make sure that your ADF Business Components runtime configuration settings are actually getting set to what you think they are, is to run with the ADF Business Components diagnostics turned on -- which you do by adding the Java VM parameter -Djbo.debugoutput=file -- and then grep through the diagnostics files that will be named bc4j*.log in the system temp directory for the ADF configuration property name. The diagnostic output will tell you the value that it is using for each configuration property, and it will tell you where it read that value from (your configuration "client environment", System Property, etc.).

Check you browser limitations with this tool.