jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Boston <ianbos...@googlemail.com>
Subject Re: Spring transactions for Jackrabbit and MySQL in Tomcat
Date Thu, 26 Mar 2009 10:47:58 GMT
Jackrabbit by default does not lock the underlying nodes that are  
being modified, it uses a merge strategy to merge concurrent changes  
to identical nodes on save, however modifications to the same property  
or addition of same name siblings are non. In those situations you get  
a InvalidItemStateException on one of the updates, effectively  
optimistic locking.

If you can't afford to have one update fail, then you need to write  
lock the mergable nearest persisted ancestor to prevent other threads  
beginning a modification.

With transactions, there appears to be an added complication, which I  
cant claim to fully understand. If there are concurrent creates on  
nodes, then the I have been seeing a failure creating the node version  
history subtree. This update was not of the form that was producing  
the InvalidItemStateException but was generating something like no  
such item exception. I found the solution in this circumstance was to  
ensure, even though the update was mergable, was to take an explicit  

So if using transactions, and expecting high levels of concurrent  
writes to the same nodes or properties, I have found that explicit  
write locks are required to prevent non mergable conflicts happening.

The slight downside of this is locking is not free. If operating in a  
Jackrabbit cluster, locks will results in more journal records, but  
then using transactions will reduce the number of journal records. The  
other worry is... without ordering the lock sequence in you  
application code deadlocks become possible.... It would be nice not to  
have to resort to locks at all, and handle the failure at a higher  

BTW, there is a bug in 1.4.x that means that empty journal records are  
produced (fixed in 1.5.x)

On 25 Mar 2009, at 21:59, Kaspar Fischer wrote:

> Ian, thanks for the post. Can you explain what you mean by locking?  
> (Dead locks?)

View raw message