From users-return-12545-apmail-jackrabbit-users-archive=jackrabbit.apache.org@jackrabbit.apache.org Thu Sep 10 11:51:08 2009 Return-Path: Delivered-To: apmail-jackrabbit-users-archive@minotaur.apache.org Received: (qmail 36979 invoked from network); 10 Sep 2009 11:51:08 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 10 Sep 2009 11:51:08 -0000 Received: (qmail 99418 invoked by uid 500); 10 Sep 2009 11:51:07 -0000 Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org Received: (qmail 99375 invoked by uid 500); 10 Sep 2009 11:51:07 -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 99364 invoked by uid 99); 10 Sep 2009 11:51:07 -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 11:51:07 +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.183 as permitted sender) Received: from [207.126.148.183] (HELO eu3sys201aog003.obsmtp.com) (207.126.148.183) by apache.org (qpsmtpd/0.29) with SMTP; Thu, 10 Sep 2009 11:50:58 +0000 Received: from source ([209.85.218.226]) by eu3sys201aob003.postini.com ([207.126.154.11]) with SMTP ID DSNKSqjoCvsCK+FMPYrRvedjX70WDlt7s0rR@postini.com; Thu, 10 Sep 2009 11:50:37 UTC Received: by bwz26 with SMTP id 26so16220bwz.47 for ; Thu, 10 Sep 2009 04:50:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.75.133 with SMTP id y5mr828685faj.92.1252583434630; Thu, 10 Sep 2009 04:50:34 -0700 (PDT) In-Reply-To: <25378625.post@talk.nabble.com> References: <25378625.post@talk.nabble.com> Date: Thu, 10 Sep 2009 13:50:34 +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=windows-1252 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org On Thu, Sep 10, 2009 at 09:29, Gamba wrote: > I'm running jackrabbit 1.6.0 on jboss 4.2.3 with mysql at the backend. Al= l > the code to access the jackrabbit-api is placed in a stateless session be= an, > in different methods (add node, delete node, ...). I'm using container > managed transaction with tx_required on each method. Each method are usin= g > an own > session with a technical user (the same in all methods) to read/write acc= ess > jackrabbit. The session logout() method is called in a finally { .. } blo= cj > at the end of each method. > I have own node-types for nodes and files. > > 1) First of all I want to know if this is a common scenario or are there = any > known problems regarding > the environment? Typically it's good to have one session per request. This keeps things simple: there is one login per user and the whole request automatically one transaction (even if you don't use java tx) if you have a single sesison.save() at the end of the request. Apache Sling for example works that way and does authentication handling and session login for you and simply passes that to servlets. But of course there are cases where you want more fine control or you need to handle it more specific if you have parts that will belong to a distributed transaction. > After implementing this I'm reading something about locks and concurrent > updates and asks myself > If I need the mixin-typ mix:lockable for my own nodes. After reading the > Spec 8.4.10 I think I don't need > the mixin types and did not handle manually node-locking, because I'm > working in a transactional environment: > > "As a result, if a lock is enabled and then disabled within the same > transaction, its effect never makes it to the persistent workspace and > therefore it does nothing. In order to use locks properly (that is, to > prevent the =93lost update problem=94), locking and unlocking must be don= e in > separate > transactions." > > 2) Is it correct that I need not bother with such locking issues? Only if you want to set locks. Otherwise you just have to be aware that an exception might occur because a node has been locked by another session (if that can be the case). With transactions, I think you will get this exception on commit. > 3) So I did not expect an InvalidItemStateExcpeton? Sorry, I don't understand what you mean by this question? > 4) Have I call the session.save() method inside my method-transactions. O= r > is it saved automatically > on a the transaction-commit? You have to call it yourself, it's not done automatically. That would be crazy. The only important thing to note is that when transactions are enabled, a session save won't persist the data as it is the case w/o transactions. This will be postponed to the (successful) commit of the transaction. > 5) Are there any known session-complications with only one technical user= in > this environment? What do you mean by "only one technical user"? Regards, Alex --=20 Alexander Klimetschek alexander.klimetschek@day.com