Sorry, but you have completely mixed 2 concepts -
thread safety of application context (which is just normal Java object with its own methods) and thread-safety of the beans created by the context as specified by configuration.
Thread safety of application context means that methods of application context object may be concurrently called from many threads.
It is achieved by design and coding of application context itself.
Thread safety of the beans created by context - completely different matter,
the only garantee that Spring gives is that bean is completely configured according to config info before is given out by context. Spring do not manage access to created beans in any way or attempts any synchronization efforts on them. It is completely up to you ensure that your beans are thread-safe.
thread safety of application context (which is just normal Java object with its own methods) and thread-safety of the beans created by the context as specified by configuration.
Thread safety of application context means that methods of application context object may be concurrently called from many threads.
It is achieved by design and coding of application context itself.
Thread safety of the beans created by context - completely different matter,
the only garantee that Spring gives is that bean is completely configured according to config info before is given out by context. Spring do not manage access to created beans in any way or attempts any synchronization efforts on them. It is completely up to you ensure that your beans are thread-safe.
You may achive it by creating beans without mutable state (typical for DAOs and services) using non-shared beans (like prototype beans) or providing proper synchronization on your own.
And for HibernateTemplate, since SessionFactory is thread safe (Session is not), HibernateDaoSupport and HibernateTemplate is thread safe.