You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Frédéric Esnault <fe...@legisway.com> on 2007/06/01 12:36:28 UTC
XASession and hasPendingChanges
I have a question about the transactional version of the SessionImpl object.
It inherits the hasPendingChanges from the SessionImpl class, but my question is :
Shouldn't the hasPendingChanges from XASessionImpl take into consideration the tx status?
Or am I missing something?
Frederic Esnault
Re: XASession and hasPendingChanges
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 6/1/07, Frédéric Esnault <fe...@legisway.com> wrote:
> My use case is simple, as I said before in another mail, my company and I are
> planning to implement the checkForReferencesInContent method (and the other
> one, checkForConflictingContent). And for this, we have to know, for each session
> of the repository, if it hasPendingChanges (ie. session hasn't been changed), and
> if a transaction is running, not yet committed. This is why I have to know, from
> a session, if it is a XASession and if it is, what is the transactional status.
The pending transaction changes are kept in the XAItemStateManager
class managed by the XAWorkspace. You may need to propose a new method
to get the state of pending changes.
Alternatively, as suggested in my "raw mode" post to dev@, we might
want to explicitly restrict administrative operations like node type
removals to cases where only a single admin session is accessing the
repository.
PS. The dev@ mailing list would be better for questions like this.
BR,
Jukka Zitting
RE: XASession and hasPendingChanges
Posted by Frédéric Esnault <fe...@legisway.com>.
Of course you can ask ;)
My use case is simple, as I said before in another mail, my company and I are planning to implement the checkForReferencesInContent method (and the other one, checkForConflictingContent). And for this, we have to know, for each session of the repository, if it hasPendingChanges (ie. session hasn't been changed) , and if a transaction is running, not yet committed. This is why I have to know, from a session, if it is a XASession and if it is, what is the transactional status.
Frédéric Esnault
-----Message d'origine-----
De : dominique.pfister@gmail.com [mailto:dominique.pfister@gmail.com] De la part de Dominique Pfister
Envoyé : vendredi 1 juin 2007 17:10
À : users@jackrabbit.apache.org
Objet : Re: XASession and hasPendingChanges
You're right, there is currently no way to tell whether an
XASessionImpl is associated with a transaction and what status that
transaction might be in (as long as you're not the transaction manager
itself, of course). May I ask, what your use case is?
Kind regards
Dominique
On 6/1/07, Frédéric Esnault <fe...@legisway.com> wrote:
> Okay, I agree.
> But this does not solve my problem. It seems (or I didn't find it) that there is no way to check tx status on a XASessionImpl. It would help, to wait for the end of a transaction, for example. And if hasPendingChanges stays "limited" to the session save() operation, it does not help for tx...
>
> Frédéric Esnault
>
>
> -----Message d'origine-----
> De: dominique.pfister@gmail.com [mailto:dominique.pfister@gmail.com] De la part de Dominique Pfister
> Envoyé: vendredi 1 juin 2007 16:42
> À: users@jackrabbit.apache.org
> Objet: Re: XASession and hasPendingChanges
>
> 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édéric Esnault <fe...@legisway.com> wrote:
> > I agree on this, hasPendingChanges returning true in case of saved but uncommitted
> > 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 them
> > 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édéric Esnault - Ingénieur R&D
> > Legisway
> > 60 boulevard de la mission Marchand
> > 92400 Courbevoie La Défense
> >
> >
> > -----Message d'origine-----
> > De: dominique.pfister@gmail.com [mailto:dominique.pfister@gmail.com] De la part de Dominique Pfister
> > Envoyé: vendredi 1 juin 2007 15:17
> > À: users@jackrabbit.apache.org
> > Objet: Re: XASession and hasPendingChanges
> >
> > Hi Frédéric,
> >
> > 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édéric Esnault <fe...@legisway.com> wrote:
> > > I have a question about the transactional version of the SessionImpl object.
> > >
> > > It inherits the hasPendingChanges from the SessionImpl class, but my question is :
> > >
> > >
> > >
> > > Shouldn't the hasPendingChanges from XASessionImpl take into consideration the tx status?
> > >
> > > Or am I missing something?
> > >
> > >
> > >
> > > Frederic Esnault
> > >
> > >
> >
>
Re: XASession and hasPendingChanges
Posted by Dominique Pfister <do...@day.com>.
You're right, there is currently no way to tell whether an
XASessionImpl is associated with a transaction and what status that
transaction might be in (as long as you're not the transaction manager
itself, of course). May I ask, what your use case is?
Kind regards
Dominique
On 6/1/07, Frédéric Esnault <fe...@legisway.com> wrote:
> Okay, I agree.
> But this does not solve my problem. It seems (or I didn't find it) that there is no way to check tx status on a XASessionImpl. It would help, to wait for the end of a transaction, for example. And if hasPendingChanges stays "limited" to the session save() operation, it does not help for tx...
>
> Frédéric Esnault
>
>
> -----Message d'origine-----
> De: dominique.pfister@gmail.com [mailto:dominique.pfister@gmail.com] De la part de Dominique Pfister
> Envoyé: vendredi 1 juin 2007 16:42
> À: users@jackrabbit.apache.org
> Objet: Re: XASession and hasPendingChanges
>
> 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édéric Esnault <fe...@legisway.com> wrote:
> > I agree on this, hasPendingChanges returning true in case of saved but uncommitted
> > 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 them
> > 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édéric Esnault - Ingénieur R&D
> > Legisway
> > 60 boulevard de la mission Marchand
> > 92400 Courbevoie La Défense
> >
> >
> > -----Message d'origine-----
> > De: dominique.pfister@gmail.com [mailto:dominique.pfister@gmail.com] De la part de Dominique Pfister
> > Envoyé: vendredi 1 juin 2007 15:17
> > À: users@jackrabbit.apache.org
> > Objet: Re: XASession and hasPendingChanges
> >
> > Hi Frédéric,
> >
> > 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édéric Esnault <fe...@legisway.com> wrote:
> > > I have a question about the transactional version of the SessionImpl object.
> > >
> > > It inherits the hasPendingChanges from the SessionImpl class, but my question is :
> > >
> > >
> > >
> > > Shouldn't the hasPendingChanges from XASessionImpl take into consideration the tx status?
> > >
> > > Or am I missing something?
> > >
> > >
> > >
> > > Frederic Esnault
> > >
> > >
> >
>
Re: XASession and hasPendingChanges
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 6/1/07, Frédéric Esnault <fe...@legisway.com> wrote:
> But this does not solve my problem. It seems (or I didn't find it) that there is no
> way to check tx status on a XASessionImpl.
I guess the proper way to do that would be to track the entire
distributed transaction that the XASessionImpl is a part of.
BR,
Jukka Zitting
RE: XASession and hasPendingChanges
Posted by Frédéric Esnault <fe...@legisway.com>.
Okay, I agree.
But this does not solve my problem. It seems (or I didn't find it) that there is no way to check tx status on a XASessionImpl. It would help, to wait for the end of a transaction, for example. And if hasPendingChanges stays "limited" to the session save() operation, it does not help for tx...
Frédéric Esnault
-----Message d'origine-----
De : dominique.pfister@gmail.com [mailto:dominique.pfister@gmail.com] De la part de Dominique Pfister
Envoyé : vendredi 1 juin 2007 16:42
À : users@jackrabbit.apache.org
Objet : Re: XASession and hasPendingChanges
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édéric Esnault <fe...@legisway.com> wrote:
> I agree on this, hasPendingChanges returning true in case of saved but uncommitted
> 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 them
> 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édéric Esnault - Ingénieur R&D
> Legisway
> 60 boulevard de la mission Marchand
> 92400 Courbevoie La Défense
>
>
> -----Message d'origine-----
> De: dominique.pfister@gmail.com [mailto:dominique.pfister@gmail.com] De la part de Dominique Pfister
> Envoyé: vendredi 1 juin 2007 15:17
> À: users@jackrabbit.apache.org
> Objet: Re: XASession and hasPendingChanges
>
> Hi Frédéric,
>
> 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édéric Esnault <fe...@legisway.com> wrote:
> > I have a question about the transactional version of the SessionImpl object.
> >
> > It inherits the hasPendingChanges from the SessionImpl class, but my question is :
> >
> >
> >
> > Shouldn't the hasPendingChanges from XASessionImpl take into consideration the tx status?
> >
> > Or am I missing something?
> >
> >
> >
> > Frederic Esnault
> >
> >
>
Re: XASession and hasPendingChanges
Posted by Dominique Pfister <do...@day.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édéric Esnault <fe...@legisway.com> wrote:
> I agree on this, hasPendingChanges returning true in case of saved but uncommitted
> 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 them
> 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édéric Esnault - Ingénieur R&D
> Legisway
> 60 boulevard de la mission Marchand
> 92400 Courbevoie La Défense
>
>
> -----Message d'origine-----
> De: dominique.pfister@gmail.com [mailto:dominique.pfister@gmail.com] De la part de Dominique Pfister
> Envoyé: vendredi 1 juin 2007 15:17
> À: users@jackrabbit.apache.org
> Objet: Re: XASession and hasPendingChanges
>
> Hi Frédéric,
>
> 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édéric Esnault <fe...@legisway.com> wrote:
> > I have a question about the transactional version of the SessionImpl object.
> >
> > It inherits the hasPendingChanges from the SessionImpl class, but my question is :
> >
> >
> >
> > Shouldn't the hasPendingChanges from XASessionImpl take into consideration the tx status?
> >
> > Or am I missing something?
> >
> >
> >
> > Frederic Esnault
> >
> >
>
RE: XASession and hasPendingChanges
Posted by Frédéric Esnault <fe...@legisway.com>.
I agree on this, hasPendingChanges returning true in case of saved but uncommitted 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 them 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édéric Esnault - Ingénieur R&D
Legisway
60 boulevard de la mission Marchand
92400 Courbevoie La Défense
-----Message d'origine-----
De : dominique.pfister@gmail.com [mailto:dominique.pfister@gmail.com] De la part de Dominique Pfister
Envoyé : vendredi 1 juin 2007 15:17
À : users@jackrabbit.apache.org
Objet : Re: XASession and hasPendingChanges
Hi Frédéric,
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édéric Esnault <fe...@legisway.com> wrote:
> I have a question about the transactional version of the SessionImpl object.
>
> It inherits the hasPendingChanges from the SessionImpl class, but my question is :
>
>
>
> Shouldn't the hasPendingChanges from XASessionImpl take into consideration the tx status?
>
> Or am I missing something?
>
>
>
> Frederic Esnault
>
>
Re: XASession and hasPendingChanges
Posted by Dominique Pfister <do...@day.com>.
Hi Frédéric,
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édéric Esnault <fe...@legisway.com> wrote:
> I have a question about the transactional version of the SessionImpl object.
>
> It inherits the hasPendingChanges from the SessionImpl class, but my question is :
>
>
>
> Shouldn't the hasPendingChanges from XASessionImpl take into consideration the tx status?
>
> Or am I missing something?
>
>
>
> Frederic Esnault
>
>