incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Jaquith <andrew.r.jaqu...@gmail.com>
Subject Re: JCR integration
Date Mon, 09 Feb 2009 03:45:13 GMT
Not sure I completely understand the issue. I do think that the
proposed remedy might be worse than the disease, though.
WikiEngine-as-singleton (more or less) is pretty easy to understand
conceptually, and the WikiEngine itself is pretty "heavyweight" in the
sense that it contains references to all sorts of other important
factories and facades that manage other things.

So, I think we should probably look to make something else
"lightweight", not the WikiEngine. What that might be, I am not sure,
because I don't fully understand the issue.

Re-reading your e-mail, I *think* I understand the comment you made
about not wanting to keep a ThreadLocal field in ContentManager that
keeps a reference to the current Session. But why keep the Session?
Couldn't a getPage() operation open a new Session, get the page, then
close the Session and return the page? Then there'd be no reason to
stash the Session anywhere.

For the most common use case (reading a wiki page), this might be
enough: the page would be wired up by Stripes anyway via
WikiPageTypeConverter. That would happen (usually) once per request.

Or alternatively, maybe you (we) guarantee that any time we get a
Session we have to complete work on the session, then call refresh(),
before returning. That would mean you could keep ThreadLocals in
ContentManager. But maybe I'm missing your point about the exception
cases. Could you explain further?

Andrew

On Sun, Feb 8, 2009 at 3:15 PM, Janne Jalkanen <janne.jalkanen@ecyrd.com> wrote:
> Folks,
>
> 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 (pagename).
>
> 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 synchronized).
>
> 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();
>
> try
> {
>   WikiPage page = engine.getPage(...);
> }
> finally
> {
>   engine.release();
> }
>
> The WikiPage object (and so the would not be valid after engine.release().
>
> 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)?
>
> /Janne
>
>

Mime
View raw message