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
