jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Poulsen" <chris.poul...@dezide.com>
Subject Trouble removing version in transaction
Date Tue, 07 Jan 2014 17:16:09 GMT

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

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  
3) Then I go through P's version history, removing everything (except root  
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

View raw message