I was wondering about the rationale for (always) pre-instantiating
singletons. Since most beans in my contexts are singletons, in practice,
I find that this brings in the kitchen sink, even when a good portion of
the stuff in the context will not be used. Now it is true that the more
heavy-weight stuff, like the Hibernate session factory, is always used.
Have people found on-demand instantiation for singletons problematic in
the past? Once issue I can see is the fact that you get feedback on
config problems much later, but this is manageable in a lot of cases
(i.e by initially running in a pre-instantiation mode, and switching to
on-demand later, etc.).
I was contrasting this strategy, and the general strategy for bean
instantiation, with HiveMind's, where HiveMind create services
completely on demand. That is, when you ask HiveMind for a service, what
it gives you back is (always) just a proxy. The initial use of that
service will force HiveMind to actually create it. If a service in
HiveMind is created, and it's properties are populated with other
services, those services will never actually be created until used. Of
course in Spring, if you get a bean from the factory, any other beans it
references as properties will also be created (unless you get into some
custom usage of interceptors in a context). Both valid approaches, but I
am just wondering if there is a use-case for supporting the HiveMind
model as well?
Regards,
Colin
|
