Actually, the default behavior for recent versions of Tomcat if the server is restarted is that the sessions persist over the restart (they're stored in the work directory as ".ser" files).
The sessionid-generating algorithm, like all hash algorithms can potentially come up with an identical ID, but the whole point of designing the algorithm is to minimize that possibility. I like Brockschmidt's quote about the chances of 2 GUIDs generating the same as "about as likely a a bunch of atoms out in space suddenly rushing together to form a small walnut".
Incidentally, if you switch from normal to SSL security in Tomcat, the session remains, but the old jsessionID is discarded and a brand-new one is generated. It still refers to the same session, but that way people cannot tap into secured communications using the unsecured handle that was public visible (unencrypted) - it's no longer attached to anything.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.