Problem with serialization:
1) Client asks for singleton from webapp and stores it as an instance variable.
2) Client get serialized to some persistance store (db, jms message queue, whatever)
3) webapp goes away (dies, gets shutdown, whatever)
4) webapp restored
5) Client deserialized.

Which version of the singleton does the Client then use? ;)

Felipe Schnack wrote:
If I write an servlet and DO NOT implement the SingleThreadModel, I
have a guarantee that I'll have only one instance of it? If not, here is
a way to do this?
No, there's no guarantee. As far as I can tell, there's no guarantee even
with SingleThreadModel.
As far as I understand it, if you implement SingleThreadModel you can actually guarantee that you have more than one instance :-)


Only way to ensure this would be to make the Servlet itself simply a facade
(Front end) to a different class that is basically a Singleton.
Hmmm... wow

Mind you this won't work if more than one JVM is perhaps involved, and
Singletons can bring up painful issues regarding serialization of sessions
if they happen to get stuck in one.
I don't think multiple VMs is an issue... you would certainly have, in this
case, multiple singletons loaded (one for each VM), but all of your other classes would be isolated from one of them anyway
Why there are problems with serialization?

Otherwise, it would be straightforward, but you'll be synchronizing like a
mad man, so don't expect a lot of throughput to multiple clients.

Of course, the real question is not whether it's possible, but why is it
necessary?

Regards,

Will Hartung
([EMAIL PROTECTED])




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>





--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to