Hi Paddy, This is actually more or less, what we are doing in Sling: We are using shared mapping configuration and just creating the mapper (and other helper) objects when creating ObjectContentManager for a session [1].
In the context of an HTTP Request we then have one ObjectContentManager instance per request whereas the mapping configuration is shared by all ObjectContentManager instances. Session management is done in another factory and behind the scenes we in fact have session pooling. Hope this helps. Regards Felix [1] http://svn.apache.org/repos/asf/incubator/sling/trunk/jcr/resource/src/main/java/org/apache/sling/jcr/resource/internal/mapping/ObjectContentManagerFactory.java Am Mittwoch, den 16.01.2008, 09:47 -0800 schrieb Padraic Hannon: > While working with the caches and with our own internal content > mapping project I have noticed a slight disconnect between how OCM > handles sessions and how jackrabbit seems to want to handle them. With > the OCM one tends to have a long lived object content manager that is > potentially used by multiple threads. This would mean that the session > would be re-used across multiple reader and writer threads. See > http://markmail.org/message/f5lbenhnmdc2vxhx > for details on threading and sessions. > > I think this points to the need to have sessions opened and closed > much like in the hibernate model. To accomplish this I think we should > create a ObjectContentManagerFactory which can create the managers so > that each thread can get its own copy. When creating a manager the > factory could use a session factory much like the one that spring has > for JCR (org.springmodules.jcr.JcrSessionFactory). This would allow > sessions to be pooled or created as needed and then be passed to > ObjectContentManagers. The factory could also preload the mapping > classes and other configuration items (like say the cache > implementation factory?). The threads could share a cache (if the > implementation is EhCache or something intelligent) or the cache could > just be a simple hashmap and the assumption would be that the managers > are short lived and the cache is there to eliminate the infinite load > issue. > > WDYT? > > -paddy >
