Great if it works, but you're basically using two different persistence mechanisms, and I'm guessing the default cookie method is the one being honored. But again, I think we're talking about different things here. The persistence profiles are used to control server affinity in a load balanced environment - making sure that a client request is sent to the same server every time. There are a lot of ways to do this, including the default cookie persistence which generates a cookie from the BIG-IP to the client, and the "universal" persistence option that allows you to write an iRule that controls affinity based on something in the client request (ie. the JSESSIONID cookie from the server). And then there's application session management. Separate from affinity, this is how an application knows that a new HTTP request is coming from an existing user "session". This has absolutely nothing to do with server load balancing affinity, but obviously affinity helps session management work since you generally need to get that server session cookie back to the same server.
Ultimately though, if you're trying to control the expiration of an application session, the load balancing persistence function is not generally going to help with that. If you kill the server affinity session/cookie, then the load balancer just load balances to a new server. You need to control the application session cookie (ie. JSESSIONID), and most likely you want to delete it when the user logs out. If you can do that from the application itself that's probably best, but you can certainly delete a client's cookies from the BIG-IP with an iRule assuming you have something unique to trigger that function (like a unique logout URI).
Nimbostratus
