jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Boston <...@tfd.co.uk>
Subject Re: Multiple Concurrent Users updating a Single Node
Date Sat, 19 Dec 2009 09:05:57 GMT

On 19 Dec 2009, at 06:35, Vibhu Sharma wrote:

> Hi,
> This may be slightly off topic from the current mailing list.
> 
> I have a Content node(nt:file) which stores the content and other metadata
> data as properties. On a high traffic site there may be a case in which a
> Single Content property (other than the jcr:data) is updated by many users(
> eg. cumulative likes and dislikes or total views). What should be the
> strategy to handle this use case?
> 
> 1. A Standard Lock and update strategy will lock out another user updating
> the same node at the same time.
> 2. A Queue system where all the updates are queued up and synced later

Depends if you ever intend to run in a cluster. 
If not you might consider a in memory locking mechanism to serialize that area of the request
cycle, however that *will* eventually become a bottleneck. At which point a queue will make
much more sense, something like posting the likes dislikes to JMS and then having a single
listener processing the results. If you need it to scale, dedicate a listener to the processing,
or beyond that shard the listeners based on the path to the object.

A JCR lock creates traffic in the JCR as the node is locked and unlocked, its really more
suitable for long lived user bound actions rather than ensuring transactional concurrency.

One alternative option is to build a subtree of nodes under the content node and avoid contention
all together, if you date stamp the like/dislike then you can use a JCR query to order the
results.

Ian

> 
> 
> regards
> Vibhu


Mime
View raw message