Dispose a singleton instance

[oz_ko]

Hi all,

I was wondering if there is a way to dispose of a singleton instance and get the container to regenerate a new instance when called? Something like context.dispose( object );

I know this sounds more like a factory method but I only ever want one instance of an object in the context at any given time.


thanks,
Oz

[Rick Evans]

Hi Oz

This is not currently supported.

Can you actually give me a concrete use case for where this functionality would be appropriate? In particular, what are the semantics associated with disposing of a singleton object when said singleton object is referenced by numerous other objects... they will all be (pretty much) invalidated as soon as Dispose() is called on the disposed object ('cos they won't be able to call any methods on the Dispose()d reference).

If you actually detail your use case then I'm sure I (and the others) will be able to provide a solution... but at the moment it seems kinda woolly as to why you would want to do this, hence the woolly response :)

Cheers
Rick

[oz_ko]

I have a hibernate configuration that is initialized at startup which is a singleton instance that builds an ISessionFactory object (which is also a singleton).

At some point the user may decide to switch databases which means I have to again configure hibernate and rebuild the ISessionFactory object.

At the moment I publish a change event which triggers the reconfiguration. I could store configuration(s) in a hashtable and return the current ISessionFactory, however this means DB connections are left open when they are not required and changing DBs is pretty infrequent.

The simplest way (in my mind at least) is to dispose of the singleton and get spring to reload with the new configuration when required.

I would think there would be other times when it'd be useful to dispose of singletons though I can't think of them atm.

Thanks,
Oz

[oz_ko]

Hi again,

I've re-read your post - Hmm... I can see the problem with disposing a referenced singleton. I would say it would be a bad idea to implement my suggestion since it could wreck a bit of havoc in existing code.

Maybe the solution would be have an disposable singleton so there would have to be a conscious decision to use this type of singleton object.

Maybe something like:

<object id="MySingleton" type="MyPackage.MySingleton, Assembly" singleton="disposable"/>

As for the objects referenced by the singleton you could walk down the object graph and dispose only the object that are defined as singleton="disposable". That would mean the existing singleton symantics are preserved for objects that should not be disposed.

Oz

[Aleks Seovic]

I think this really needs to be handled in the application code, not in the framework.

To address your use case, you could write an IFactoryObject implementation that either returns current ISessionFactory or disposes current one and creates a new one when Hibernate configuration object changes.

For example, your configuration object could have ChangeDatabase method that would load new configuration and raise DatabaseChanged event. HibernateSessionFactory would implement IFactoryObject interface and listen for DatabaseChanged event. When the event is raised, it would clean up/dispose existing ISessionFactory and obtain a new one from the configuration object, which would now become current session factory.

This way you get a "singleton-that-changes-from-time-to-time" :-) Oh yeah, you also need to make sure that HibernateSessionFactory's IsSingleton property returns false, to make it look like a prototype to other objects.

Later,

Aleks

[Aleks Seovic]

Now that I reread my message, it probably makes sense to build this functionality into the framework, but not at the level you were proposing.

We can probably implement this as part of NHibernate integration implementation.

- Aleks