jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Klimetschek <aklim...@day.com>
Subject Re: Confirming assumptions about transactional environment and session-handling
Date Thu, 10 Sep 2009 13:43:15 GMT
On Thu, Sep 10, 2009 at 14:43, Gamba <holger.breuer@handelshof.de> wrote:
> Hm. I thought, in a transactional environment the locks are released on
> a session commit when I use session-scoped locks and I thought that's the
> only
> useful thing in that case.
>
> So I wonder if I need any locking in my environment?

Well, that simply depends if your application logic requires locking.

> And that the reason I thought there will not be such exceptions,
> because all changes are persisted at commit-time. Hm ... ok,
> when another session updates the same node, then the exception
> could occur ... Is it possible to use refresh() in that case, before
> saving the session?

No, because refresh(true) in Jackrabbit will have no effect (because
Jackrabbit employs copy-on-write) and refresh(false) would discard the
changes of your session.

> At the moment, we have only one and same user for all session-logins calling
> ...
> repository.login(new SimpleCredentials("technical", "passwd".toCharArray()),
> "default");

JCR is more designed to log in with the "real" users and not use a
technical user like it's typical with relational databases.

>
> We ware in test-state at the moment and not in production with our
> application.
> But in production I think we need also only one user, because our
> authentication-access
> is done in a speparate component. So are there any problems which can occur
> with only one user
> to acces jackrabbit with multiple thread calling staless-sb-methods and each
> method
> getting the session with the shown statement?

It's the session that counts, not the user. If you have two sessions,
they can conflict, but this has nothing do to what the users behind
the session are.
Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com

Mime
View raw message