I'm using newest Apache2, newest mod_perl.

That does not change even one bit in the HTTP protocol, so it is (nearly) irrelevant.

I do not need nor want to store the connections on disk. I would simply want that within a session a network connection is opened, and remains open as long as the session is active. Which means the network connections life should extend - of course - the life of the running apache processes that happen during that session. That's the whole problem.

Serialisation does not necessarily mean writing to disk. It just means to generate a string of bytes representing a complex structure. And you can't to that with a network connection, because you literally hold only one end of the connection.

Basically, you want to extend the session handling to also manage a network connection. A naive implementation would use a hash, using the session ID as key and the file handle of the socket (network connection) as the key. Whenever you create a new session, you also generate a new socket, and store both in the hash. Whenever the session is closed or expires, you close the socket and remove session ID and socket handle from the hash.

A better solution would be to separate connection and session also in the backend. If you use some kind of remote procedure call API, create a new session in the backend and get a handle (a simple, random number) back. Use that handle for all interactions during the session, and destroy the handle when the session is terminated or expired. Connect to and disconnect from the backend as needed.

The backend is not a DB, but an own server process

As most DBs are separate server processes, this is irrelevant, too. In fact, it does not matter if you connect to a DB server, an FTP server, or a coffee machine server.

Alexander