jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: "Unable to lock node. Node has pending changes: /counter"
Date Tue, 20 Jun 2006 10:48:50 GMT
Hi,

On 6/20/06, Torgeir Veimo <torgeir@pobox.com> wrote:
> On Tue, 2006-06-20 at 12:12 +0200, Marcel Reutegger wrote:
> > well, you can reuse the session, but you must not shared it among
> > multiple threads. Unless you synchronize access to the session.
>
> What's the recommended practice with web application? doing a login and
> logout for each request?

There are a number of different patterns with different benefits and
drawbacks. Some examples:

1) Session per request. This is the simplest solution but not very
performant at least with the Jackrabbit architecture.

2) Session per session. This is probably the most common pattern, i.e.
you associate a JCR session with the servlet session and make sure
that the session access is synchronized.

3) Session per user. Used when it is likely that a user can have
multiple concurrent browser sessions and that there are no problems
with making transient changes visible across sessions. Requires
synchronization, but scales otherwise very well for cases like
anonymous access.

4) Session per feature. Use a separate session associated with a
specific feature, like a single servlet. Requires synchronization and
doesn't support per-user access controls, but is often more
fine-grained than pattern 3.

5) Session per application. A global session used by all parts of the
application. Requires heavy synchronization and doesn't support
per-user access controls, but is conceptually very simple.

6) Session pool. Meta-pattern that uses a pool of sessions to avoid
performance or synchronization issues in the other patterns.

It is also possible (and often useful) to combine these patterns in a
single application.

BR,

Jukka Zitting

-- 
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development

Mime
View raw message