jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vibhu Sharma <vi...@projectoffguard.com>
Subject Re: Multiple Concurrent Users updating a Single Node
Date Sun, 20 Dec 2009 09:52:30 GMT
Thanx Ian for the quick response.
I'll look into the JMS option and share my experience.

The subtree alternative is also quite interesting.
Extending on the same thought, I was thinking to store all the user
generated data (likes etc.) in a separate workspace with a softlink to the
main content node. This way the Content workspace will have considerably
less data.

regards
Vibhu

On Sat, Dec 19, 2009 at 2:35 PM, Ian Boston <ieb@tfd.co.uk> wrote:

>
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message