Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of ianboston@googlemail.com
 designates 209.85.219.217 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=googlemail.com; s=gamma;
        h=sender:content-type:mime-version:subject:from:in-reply-to:date
         :content-transfer-encoding:message-id:references:to:x-mailer;
        b=pLY5f5WoPxSjg/hCiueoNhrQvfz54H7xbuRlyRCwfMsW2tdDNhlEOSa4IlzVllwQDu
         0qPwEllxpt5Orcs979Z8lGajfMLgx161pB9+s0JccsRyjO1WNbXLD+LNJJK9CfUgDbN6
         JBPJgidiEMLix29Oo4uOBPAaYVWR/qYGFbKU4=
Sender: Ian Boston <ianboston@googlemail.com>
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1077)
Subject: Re: Multiple Concurrent Users updating a Single Node
From: Ian Boston <ieb@tfd.co.uk>
In-Reply-To: <b9107ade0912182235v39488b77j228a0c2fe09bb17d@mail.gmail.com>
Date: Sat, 19 Dec 2009 09:05:57 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <4320895C-247C-4DD3-A683-A934C93B3406@tfd.co.uk>
References: <b9107ade0912182235v39488b77j228a0c2fe09bb17d@mail.gmail.com>
To: users@jackrabbit.apache.org


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

> Hi,
> This may be slightly off topic from the current mailing list.
>=20
> 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?
>=20
> 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.=20
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

>=20
>=20
> regards
> Vibhu