I'm most familiar with GWT-RPC and it doesn't have any backward compatibility built in, so most deploys are a protocol change. (It does at least give you a clear error when there's a protocol mismatch.)
So if you want old user sessions to survive, you'll need to keep the old service available until they reload the page.
There are protobuf/JSON-based alternatives with a better compatibility story.
It's not true that most deploys are a protocol change - only changes that would also change Java serialization's serial UID will cause GWT-RPC clients to become incompatible.
I routinely deploy a new version while hundreds of users are online and nobody is the wiser.
Actually there is backwards compatibility in the same sense as there is binary compatibility. Have a mechanism to force upgrades, ideally conserving state. Leave the old call in place for 1 version.
This is not difficult.
Protobuf/JSON alternatives don't even have frontend-backend compatibility in the same version. Protobuf in java has completely different encoding to normal protobuf, meaning you need TWO protobuf libraries in your backend, and of course javascript protobuf messages don't actually support anywhere near the language set that protobuf itself supports. Those are reasons why calling it protobuf is misleading. The data structures don't mean the same thing in the frontend and the backend.
So if you want old user sessions to survive, you'll need to keep the old service available until they reload the page.
There are protobuf/JSON-based alternatives with a better compatibility story.