do %session.Logout()

Ends the session. Next request starts the new session.

I know that this ends the session, but an approach could be with one client request end it, and return a new one. With this solution you need to wait until the next request to create the new one so you no longer know if the client is authenticated.

The other option as mentioned is to encript trafic and therefore the cookie can no longer be used.

That is right, but as long as the cookie session timeout is valid (let's say 60 seconds) anybody that intercepts that cookie is effectively authenticated as long as the timeout is valid.

Some ideal situation as mentioned by Joan would be to have a cookie that is used since the user accesses the first page until it want's to log in, and then, when the login request is received, invalidate that cookie and sessionID, create a new session identifier and return it.

Isn't there any way of invalidating a sessionID manually and creating a new one?

I did some test back ago about backing up mirror scenarios (and restoring them), with an arbiter and hot backups.

There is indeed an important thing to keep in mind to avoid an final awkward situation, both nodes (A and B) end up in secondary mode and therefore readonly: this happens if you have both nodes up and synced, you turn off your primary (A) node (to backup or for maintenaince) then your secondary (B) becames primary, for whatever reason you remove the mirror configuration (in B as primary) and then A goes online again.

We found this situation in a scenario where B was kept as primary for some time, decided to remove mirror configuration, and then A was brought online,  for some reason both become secondary and readonly and the only solution was to restore a backup in the "most" functional node that was B.

As stated by user Mario Sanchez on the spanish community:

The query freezing are based on cached queries, so we can assure that if there are no cached queries there will no be frozen queries. 

Saying that, the best way to be sure to not have frozen queries:

  1. Unfreeze
  2. Purge

It can be that overwriting the LOGIC some queries are automatically purged, and the later would not be needed, but knowing that both steps are fast and clear we can take it as assured.

How would this meet with mirroring?

I know that mirroring wont sync HS configuration (such as mappings) and this will have to be done manually with some process running in both sides to keep the configuration consistent.

The problem that I foresee is being able to do the mapping synchronization at the exact same instant (in index meaning) so that no inserts are lost between the database "PERSONADATA2" creation in the primary and the creation in the secondary.