From users-return-12548-apmail-jackrabbit-users-archive=jackrabbit.apache.org@jackrabbit.apache.org Thu Sep 10 13:43:53 2009
Return-Path:
Delivered-To: apmail-jackrabbit-users-archive@minotaur.apache.org
Received: (qmail 75434 invoked from network); 10 Sep 2009 13:43:52 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
by minotaur.apache.org with SMTP; 10 Sep 2009 13:43:52 -0000
Received: (qmail 95690 invoked by uid 500); 10 Sep 2009 13:43:52 -0000
Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org
Received: (qmail 95663 invoked by uid 500); 10 Sep 2009 13:43:52 -0000
Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: users@jackrabbit.apache.org
Delivered-To: mailing list users@jackrabbit.apache.org
Received: (qmail 95652 invoked by uid 99); 10 Sep 2009 13:43:52 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 Sep 2009 13:43:52 +0000
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of aklimets@day.com designates 207.126.148.181 as permitted sender)
Received: from [207.126.148.181] (HELO eu3sys201aog001.obsmtp.com) (207.126.148.181)
by apache.org (qpsmtpd/0.29) with SMTP; Thu, 10 Sep 2009 13:43:42 +0000
Received: from source ([209.85.220.224]) by eu3sys201aob001.postini.com ([207.126.154.11]) with SMTP
ID DSNKSqkCeKVekLdLaPzA247Zw3TKJ8zTc49g@postini.com; Thu, 10 Sep 2009 13:43:22 UTC
Received: by fxm24 with SMTP id 24so112618fxm.11
for ; Thu, 10 Sep 2009 06:43:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.25.27 with SMTP id x27mr1055870fab.7.1252590195281; Thu,
10 Sep 2009 06:43:15 -0700 (PDT)
In-Reply-To: <25382645.post@talk.nabble.com>
References: <25378625.post@talk.nabble.com>
<25382645.post@talk.nabble.com>
Date: Thu, 10 Sep 2009 15:43:15 +0200
Message-ID:
Subject: Re: Confirming assumptions about transactional environment and
session-handling
From: Alexander Klimetschek
To: users@jackrabbit.apache.org
Content-Type: text/plain; charset=ISO-8859-1
X-Virus-Checked: Checked by ClamAV on apache.org
On Thu, Sep 10, 2009 at 14:43, Gamba 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