My application can call configuration.buildSessionFactory on more than one
Configuration instance in multiple threads. Im seeing weird error (see stacktrace below ) and my theory is, after eyeballing the src code, that when using the EHCache( default) calling buildSessionFactory is not thread safe, even if it is called on separate Configuration instances!
Looks like that the CacheManager is a singleton, and the buildSessionFactory method refers to it without synchornizing...Is this a Hibernate/EHCache bug?

Thanks:

Got a HibernateException while initializing the HibernateDAO net.sf.hibernate.cache.CacheException: net.sf.ehcache.ObjectExistsException: Cache net.sf.hibernate.cache.UpdateTimestampsCache already exists
at net.sf.hibernate.cache.EhCache.<init>(EhCache.java:101)
at net.sf.hibernate.cache.EhCacheProvider.buildCache(EhCacheProvider.java:84)
at net.sf.hibernate.cache.UpdateTimestampsCache.<init>(UpdateTimestampsCache.java:36)
at net.sf.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:210)
at net.sf.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:791)
at com.jpmorgan.gcrm.rbrm.common.util.HibernateDAO.init(HibernateDAO.java:150)
at com.jpmorgan.gcrm.rbrm.clientmgmt.dao.ClientDAOImpl.init(ClientDAOImpl.java:55)
at com.jpmorgan.gcrm.rbrm.common.util.HibernateDAOFactory.init(HibernateDAOFactory.java:35)
at com.jpmorgan.gcrm.rbrm.common.util.HibernateDAOFactory.getHibernateDAO(HibernateDAOFactory.java:25)
at com.jpmorgan.gcrm.rbrm.clientmgmt.dao.ClientDAOFactory.getClientDAO(ClientDAOFactory.java:15)
at com.jpmorgan.gcrm.rbrm.clientmgmt.dao.DALController.getClientDAO(DALController.java:110)
at com.jpmorgan.gcrm.rbrm.clientmgmt.dao.DALController.getClient(DALController.java:55)
at com.jpmorgan.gcrm.rbrm.clientmgmt.ClientsMgrEJB.getClient(ClientsMgrEJB.java:94)
at com.jpmorgan.gcrm.rbrm.clientmgmt.ClientsMgrEJB_y8qi8w_EOImpl.getClient(ClientsMgrEJB_y8qi8w_EOImpl.java:46)
at com.jpmorgan.gcrm.rbrm.app.client.ClientController.getClient(ClientController.java:164)
at com.jpmorgan.gcrm.rbrm.app.ProcessClientMgrEJB.getClient(ProcessClientMgrEJB.java:239)
at com.jpmorgan.gcrm.rbrm.app.ProcessClientMgrEJB_7zip28_EOImpl.getClient(ProcessClientMgrEJB_7zip28_EOImpl.java:626)
at com.jpmorgan.gcrm.rbrm.app.ProcessClientMgrEJB_7zip28_EOImpl_WLSkel.invoke(Unknown Source)
at weblogic.rmi.internal.ServerRequest.sendReceive(ServerRequest.java:166)
at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:284)
at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:244)
at com.jpmorgan.gcrm.rbrm.app.ProcessClientMgrEJB_7zip28_EOImpl_812_WLStub.getClient(Unknown Source)
at com.jpmorgan.gcrm.rbrm.web.actions.ViewClientAction.execute(ViewClientAction.java:145)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:484)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:274)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:507)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:971)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:402)
at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:28)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
at com.jpmorgan.gcrm.rbrm.app.filter.EntitlementFilter.doFilter(EntitlementFilter.java:82)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6356)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3635)
at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2585)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
Caused by: net.sf.ehcache.ObjectExistsException: Cache net.sf.hibernate.cache.UpdateTimestampsCache already exists
at net.sf.ehcache.CacheManager.addCache(CacheManager.java:265)
at net.sf.hibernate.cache.EhCache.<init>(EhCache.java:96)
... 41 more

Hi.

Why don't you use the same SessionFactory through all of your application?

I think the meaning of thread-safe is that if two threads access the same instance, nothing will happen to it.
Here you describe that you have multiple instances of the SessionFactory.

In Hibernate reference it says that the SessionFactory holds the second level caching, and if you have multiple SessionFactory's, you might be in problem with the caching.

look at the class HibernateUtils in CaveatEmptor, and you will see that the same SessionFactory is used through the whole application.

Jus.[/i]

An instance of SessionFactory is perfectly thread safe. That's not the issue. The problem is that the buildSessionFactory method on the Configuraiton class is NOT, even when called on DISTINCT Configuration instances!! This seems to be a pretty signifcant bug...

fyi, there are many reasons two have more than one SessionFactory instance. For example, you might be accessing more than one DB, and want to map the same object hierarchy to both DBs. The only way to do this in Hibernate is with distinct session factories. Another example is mapping the same object to two different tables in the same DB, as I do in my app. For have example, I have a CLIENT and a CLIEN_HIST table, which are exactly the same. Every time a client is updated a new row is inserted into the CLIENT_HIST table ( for audit trail purposes ), as well as a row in the CLIENT table is updated. That way, when you're interested in the latest client info, you don't have to search through the milllions of rows in the CLIENT_HIST table, but simply look in the much smaller CLIENT table.

Anyway, there are other reasons as well...