Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (herse.apache.org: domain of dominique.pfister@gmail.com
 designates 209.85.146.181 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=HspY1sI0WpulUQv6KtCSA8P9omqI4M45VgsKCMU/juFdBYcynYTUlv9nQcpRoEpMbePBfi7hMxdcqMmZNAKAtHQRZ++fnFuPTkptqKCNNQImAUNDHWyKsVP7ibOfjIw7mxCspD8h5Rjctv0lNOpvTKSZaIJIkeyMH6ntc6+B4H4=
Message-ID: <66c10f230706010742t250aa5fep89a36615670b4364@mail.gmail.com>
Date: Fri, 1 Jun 2007 16:42:22 +0200
From: "Dominique Pfister" <dominique.pfister@day.com>
Sender: dominique.pfister@gmail.com
To: users@jackrabbit.apache.org
Subject: Re: XASession and hasPendingChanges
In-Reply-To: <EC213738EDD1C348BBE6012077FB746B07785B@asterion.legisway.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <66c10f230706010617u52ab1e5fv156d158e3beecb3b@mail.gmail.com>
	 <EC213738EDD1C348BBE6012077FB746B07785B@asterion.legisway.com>

Well, the merge of two nodes will be part of the transaction, too. At
the end of the transaction, all operations inside that transaction -
whether or not related to versioning - will either be committed as an
entity or rolled back.

Kind regards
Dominique

On 6/1/07, Fr=E9d=E9ric Esnault <fesn@legisway.com> wrote:
> I agree on this, hasPendingChanges returning true in case of saved but un=
committed
> tx would create some difficulties, especially in a case like the one you =
submitted.
>
> But...wouldn't it be dangerous to allow a merge of two nodes if one of th=
em
> is potentially modified by an uncommitted transaction? The merge can
> succeed before tx commit, and fail after commit, which is a situation
> hasPendingChanges not taking care of tx would allow. Am I wrong?
>
> Fr=E9d=E9ric Esnault - Ing=E9nieur R&D
> Legisway
> 60 boulevard de la mission Marchand
> 92400 Courbevoie La D=E9fense
>
>
> -----Message d'origine-----
> De: dominique.pfister@gmail.com [mailto:dominique.pfister@gmail.com] De l=
a part de Dominique Pfister
> Envoy=E9: vendredi 1 juin 2007 15:17
> =C0: users@jackrabbit.apache.org
> Objet: Re: XASession and hasPendingChanges
>
> Hi Fr=E9d=E9ric,
>
> according to the specification, hasPendingChanges should return true
> if the session has unsaved changes. Some operations (e.g.
> javax.jcr.Node.merge(String, boolean)) rely on a session not having
> any pending changes. Some client could perfectly use code such as
>
> node.addNode("child");
> node.getSession().save();
> node.merge("sourcews", true);
>
> If an XASessionImpl has saved but uncommitted changes - this is
> probably the case you're referring to, isn't it? - it could decide to
> return true in its hasPendingChanges implementation. However, the same
> client, unaware of the transactional nature of its session, would
> never be able to execute the same piece of code shown above, because
> the session would still report pending changes. In other words, a
> client would have to detect whether or not it runs in a transactional
> environment, which is probably not what you want.
>
> Kind regards
> Dominique
>
> On 6/1/07, Fr=E9d=E9ric Esnault <fesn@legisway.com> wrote:
> > I have a question about the transactional version of the SessionImpl ob=
ject.
> >
> > It inherits the hasPendingChanges from the SessionImpl class, but my qu=
estion is :
> >
> >
> >
> > Shouldn't the  hasPendingChanges from XASessionImpl take into considera=
tion the tx status?
> >
> > Or am I missing something?
> >
> >
> >
> > Frederic Esnault
> >
> >
>