incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Janne Jalkanen <>
Subject JCR integration
Date Sun, 08 Feb 2009 20:15:24 GMT

I've got a bit of a problem with respect to the JCR integration.  I  
will write a lengthy email explaining my current thoughts on the  
subject partly to get your ideas, and partly to clarify my own  
thoughts on the subject.

Our current model is stateless in the sense that the repository is  
open all the time, and you just access the pages with a String handle  

However, JCR model is stateful.  That is you first get a Session  
object, through which you manipulate the contents of the repository,  
and once you're done, you release that object.  This is similar to  
Hibernate, though JCR Sessions are not threadsafe (and assumed to be  
bound to a single Thread even, so they can't even be shared when  

So logically we *could* have ContentManager have a single ThreadLocal  
which keeps the Session object. However, since a Session gathers all  
of the changes, it means that in case of e.g. exceptions, the old data  
would still remain somewhere in the Session, and upon a new save, some  
old, obsolete data would be saved as well.  This is obviously not a  
good thing.

No, we can't empty the Session with Session.refresh() before access  
simply because we don't know when access begins - it could start even  
with a simple getPage() - and obviously it's not a good thing if you  
call getPage() multiple times during a single access.

So, it seems to me that in order to avoid side effects, we need to  
have some sort of session management - which means acquiring a session  
to the JSPWiki repository, and then also releasing it.  The WikiEngine  
object would be an obvious place for it, since it's what's being  
passed around anyway.

So the proposal would be to have a WikiEngineFactory object, which you  
would call as follows:

WikIEngine engine = WikiEngineFactory.getEngine();

    WikiPage page = engine.getPage(...);

The WikiPage object (and so the would not be valid after  

Now, this does not mean that the Factory will create new WikiEngines,  
but it'll probably set up some ThreadLocals so that it'll work  
properly.  If we had separate WikiEngine objects, we would need to  
recreate all of our Manager classes.  This unfortunately means that  
WikiEngine is for all intents and purposes currently a singleton.   
However, this approach would work, since you can't get to the managers  
without getting a WikiEngine first.

Anybody see any serious problems with this approach?  Anything that'll  
break (other than every single plugin/Task which holds a reference to  
a WikiPage or WikiContext object, but those can be refactored away)?


View raw message