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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Dominique Pfister Envoyé: vendredi 1 juin 2007 16:42 À: [email protected] 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Dominique Pfister > Envoyé: vendredi 1 juin 2007 15:17 > À: [email protected] > 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 <[EMAIL PROTECTED]> 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 > > > > >
