Multiple Concurrent Users updating a Single Node

[Vibhu Sharma <vi...@projectoffguard.com>]

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


regards
Vibhu

Re: Multiple Concurrent Users updating a Single Node

[Torgeir Veimo <to...@netenviron.com>]

2009/12/20 Vibhu Sharma <vi...@projectoffguard.com>:
> 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.

Please share you experience as you get this implemented. We need a
view count for forum threads which is quite similar in requirements.

-- 
-Tor

Re: Multiple Concurrent Users updating a Single Node

[Vibhu Sharma <vi...@projectoffguard.com>]

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 <ie...@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
>
>

Re: Multiple Concurrent Users updating a Single Node

[Ian Boston <ie...@tfd.co.uk>]

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