In my work application there are 3 singleton classes.

The first is the CGI object, which inherits from the (non-singleton) 'site' object (the configuration of this installation of the app), and adds to it the CGI-specific I/O capabilities. It is created at BEGIN time and stored in a lexical variable at the package scope to ensure its singularity.

The second is the logging object, which captures most stderr output and splits it to a per-script, per-site logfile. It is created when needed (though at BEGIN time in the case of a CGI invocation), and stored in a lexical variable at the package scope to ensure its singularity. Arguably it should not be - certain scripts need to deal with information from multiple sites - but I haven't yet worked out what correct behaviour really is in such cases, and current behaviour hasn't proved a problem to date.

The third is arguably not a singleton: it is the database class that mediates access to the 'site' table, containing the client-modifiable configuration options. This uses our base database abstraction layer, but overrides the insert/delete mechanisms to ensure that the given site has only one entry in the table.

None of these are serialised per se, except in the sense that the fields of the last one are serialised to store them in the database.

Hope this is of some use as a data point,

Hugo