Persistence Table and Client Connections

A new login probably creates a new TCP connection, which will reset the persist table timers. The big-ip will see a new connection request, 3-way handshake the client, lookup in the persist table. It finds a persist record for that sourceIP, DOES NOT load balance and follows the persist table, opens a new connection to the server, and resets the age timer on the persist record.

This is how it is supposed to work.

You have to also consider other TCP timeouts. The client TCP stack, the server TCP stack, and especially the EBS/Forms application timers. If those are lower, they will often close/reset TCP connections. When big-ip sees that, it honors the request, AND removes the persist table record. With no persist record, big-ip will then load balance any new TCP connections from that same sourceIP.

There are also TCP Idle Timeout values. Any connection through big-ip without any activity will be closed at 5 minutes ( the default setting ), also clearing the persist table entry. So Idle timeout values play a large role in TCP connections as well.

One other thought - I see from your description, you are load balancing through VIPs for EBS login, but not for FORMS ? You are allowing the Forms server and client to interact directly, bypassing big-ip ? You could run the forms traffic through big-ip as well, and enable "Match Across" vips/pools. However, some developers hard code IPs in their forms, which again will tell the client to bypass big-ip. And sometimes the FORMS process will pick random TCP ports and other ugly, non load-balancer friendly behaviours, so this may not be an option.

In general, you do not need large persist timers. If EBS/Forms application timeouts are about 15 minutes, then 20-30 minute persist timers will suffice just fine. The persist table will clean itself whenever a tcp connection is closed/reset.

You could always follow the Oracle and F5 deployment guides for EBS, and use Cookie persist as recommended, and TCP Idle Timeouts at 30 minutes.

Good Luck, Chris.