I completely agree with Paddic. It should be nice to see this session pool in the jackrabbit project.
Christophe On Jan 18, 2008 7:40 PM, Padraic Hannon <[EMAIL PROTECTED]> wrote: > The more I dig into the Sling code the more I wonder if the pooled > session implementation should be part of the core jackrabbit code. The > pooled implementation would be extremely valuable to the OCM part of > jackrabbit and would probably be great for others as well. > > See > > > http://svn.apache.org/repos/asf/incubator/sling/trunk/jcr/api/src/main/java/org/apache/sling/jcr/api/internal/PooledSession.java > > > -paddy > > On Jan 18, 2008, at 9:13 AM, Padraic Hannon wrote: > > > Yeah I had been looking at that code, perhaps I'll work on moving > > those concepts into ocm so others can have it. I was going to do our > > vehicle domain model with sling but right now I think Edmunds isn't > > ready for that so I am just using straight ocm and spring :( Once > > that part is done I am going to adapt it to Sling as I think it is a > > much nicer model than the spring config version. > > > > Pih > > > > On Jan 18, 2008, at 4:42 AM, Felix Meschberger wrote: > > > >> 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 > >>> > > > > >
