Persisting singletons to disk during shutdown

[Pho Tek]

I create a singleton class which maintains a running number (monotonically increasing). The class exposes a public method next.
If I make the class implement the Serializable
interface, will the servlet engine persist it
automatically to the hard disk on shutdown and
subsequently restore it at bootup ? And more
importantly, the singleton class should continue
farming out serial numbers from its previous
state before the shutdown.
Thanks
P/S I am using WebSphere
Pho

[Peter den Haan]

Not entirely sure, don't think so. But it seems to me that the answer really doesn't matter -- you can never rely on the servlet container calling destroy() and performing a proper shutdown. The machine or JVM might simply crash, the power might be cut...
Also, have you considered that the approach will not work at all in a distributed container?
Furthermore, when using the Singleton feature in a web-app you should realise that during development, due to class reloading, there may well be more than one version of your Class living in the JVM and therefore more than one version of your Singleton. To address this you can bind the singleton instance in the servlet context rather than in a static variable (but beware of ClassCastExceptions for reloaded non-system classes).
- Peter
[ May 09, 2002: Message edited by: Peter den Haan ]

[Pho Tek]

Peter,
Thanks for replying. Please also read my
other post on my singleton implementation
(if you have time). I would love to hear
your critique on my design.
I am aware of the problems that you mentioned
specifically about multiple instances of the singletons. Does anyone know of a way to generate
monotonically increasing numbers in a multithreaded environment and that can be persisted ? These numbers are being used as primary keys in my tables.
Another solution I've thought of is to do everything in the database. e.g. a table for counters or use proprietary data types e.g. IDENTITY constraint in SQLServer or SERIAL/SERIAL8 data type in Informix IDS.
Cheers,
Pho

[Tim Holloway]

I think you've just found a good use for an entity EJB.

[Tim Holloway]

Actually, I shouldn't have said "think". I do in fact use this method often. I have a "key table" in the DBMS that pairs table names with next-up key values and use that to back an EJB that serves up the new key values for the indicated DBMS tables.

[Peter den Haan]

Have a search and you will find various EJB-based (and otherwise-based) number generators on the 'net.
If the numbers do not need to be contiguous (which they won't be for most primary-key-sequence-generator applications), the most powerful pattern is one whereby an EJB (or Java class) allocates a batch of 10... 100... or perhaps 1000 numbers from the nextnum table, then hands them out one by one. The advantage is that there may be multiple generators in multiple JVMs, and the database still won't be a bottleneck. The disadvantage is that some numbers will go unused when the application shuts down or crashes.
Again, do a search and you'll find implementations. I seem to remember discussions on TheServerSide ages ago.
- Peter