Trouble removing version in transaction

[Chris Poulsen <ch...@dezide.com>]

Hi,

Have an application where a node P can have a property containing a  
weakreference to another node C. C can be weakreferenced from multiple  
places.

When P is deleted its version history is also removed and C should be  
removed if P was the only node referencing it.

So basically I do the following for a node P with one saved version  
(besides the root version):

1) TX begin
2) Lookup node P and store the path of the child node (C) that it  
references.
3) Then I go through P's version history, removing everything (except root  
version)
4) Then session.removeItem( node P ) + session.save()
5) Now I lookup C using the stored path (from #2) and attempt to do  
nodeC.getWeakReferences() - nodeC.getWeakReferences(<property-name>)

And then the problems occur. Using nodeC.getWeakReferences() yields an  
ItemNotFoundException, using nodeC.getWeakReferences(<property-name>)  
returns a list of 1 "referencing property" - this property is located on a  
frozen node in the version storage (it is the deleted version of node P).

Should the two Node.getWeakReferences calls not behave consistently? - And  
should version history removes not be reflected immediately in the current  
session ( /transaction ).

Currently the result is that node C ends up being orphaned after the TX is  
committed, where it should have been deleted. If I examine its  
weakreferences after the TX commit, everything works as expected.

Should VersionHistory.removeVersion changes not be reflected immediately  
in a transaction?

Having to attempt to locate and delete the "orphaned" child nodes after  
the transaction is committed seems like it defeats the purpose of having a  
transaction in the first place.

I'm, pretty sure that this worked without transactions.

Is this a bug? or is there some clever way of being able to do this. The  
actual system has large trees using this delete-if-orphaned feature, so  
having to fire up an extra transaction for every child recursively isn't  
really an option.

We're using XA transactions and Jackrabbit v2.4.4

Does anyone have some insights to offer?

-- 
Best regards
Chris

Re: AW: Trouble removing version in transaction

[Chris Poulsen <ch...@dezide.com>]

Hi,

Thank you for the quick reply!

Yes, I'm aware that session behaves differently in transactions ;-) The  
reason for my mail is that the behavior I'm seeing currently; does not  
match my expectations.

I would expect that VersionHistory.removeVersion changes are reflected  
immediately in my session (in current TX) - And they seem to be, to some  
extent.

If i examine the version history right after removing old versions they  
are not there anymore (in same TX), but the  
node.getWeakReferences(<property-name>) call still returns the properties  
 from the "removed versions".

The node.getWeakReferences() (no arg version) throws an "item not found"  
exception, indicating that it may actually have a slightly more correct  
picture of the data in the session/TX.

I would at least expect both the Node.getWeakReferences methods to behave  
in the same way (currently one throws exception while the other returns  
references to nodes in removed versions). - And I really hope that  
VersionHistory.removeVersion changes in a TX also are reflected  
immediately/consistently.

I'll start working on a test case, its not the most trivial setup with XA  
transactions etc. but I really hope that this is a bug and it will/can be  
fixed.

-- 
Chris


On Wed, 08 Jan 2014 07:42:26 +0100, KÖLL Claus <C....@tirol.gv.at> wrote:

> Hi Chris,
>
> Some behavior inside a transaction is indeed different than without  
> transaction.
> One thing is that session.save() will not perform immediately. It will  
> be saved on transaction commit.
>
> However it can be a bug as you mentioned.
> I'm not so familiar with the weak references code but could you please  
> create a testcase
> so that we can have a look at it ..
>
> greets
> claus


-- 
Using Opera's mail client: http://www.opera.com/mail/

AW: Trouble removing version in transaction

[KÖLL Claus <C....@TIROL.GV.AT>]

Hi Chris,

Some behavior inside a transaction is indeed different than without transaction.
One thing is that session.save() will not perform immediately. It will be saved on transaction commit.

However it can be a bug as you mentioned.
I'm not so familiar with the weak references code but could you please create a testcase
so that we can have a look at it ..

greets
claus