jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sessa, Romain" <Romain.Se...@experian.com>
Subject RE: FineGrainedISMLocking implementation for concurrent access. [SEC=UNCLASSIFIED]
Date Tue, 11 Oct 2011 08:25:31 GMT


Thanks for your response.


Unfortunately this solution doesn't solve our following requirements :

-          First, access control can't be a property on a node, it need
to be an "external" access control system. 

-          Secondly,  if a thread tries to access a node and it's locked
then the thread must be put on a queue in purpose to wait until node is
unlocked. As soon as node is unlocked, waiting thread resumes its
operations ( like semaphore behavior ).


Because these needs are very specifics to our business logic we are
searching a starting point on Jackrabbit API and not necessarily a
perfect solution.




Romain SESSA

Morpheus Team - Developer



From: Ross.Dyson@ipaustralia.gov.au
Sent: 11 October 2011 08:12
To: users@jackrabbit.apache.org
Subject: RE: FineGrainedISMLocking implementation for concurrent access.


Add a property that represents a locked-for-reading flag?  First thing
to do when the updating thread locks the object is to update the flag. 

From:        "De Georges, Adrien" <Adrien.DeGeorges@experian.com> 
To:        <users@jackrabbit.apache.org> 
Date:        10/10/2011 07:03 PM 
Subject:        RE: FineGrainedISMLocking implementation for concurrent


Hi guys,

Please reconsider this email as we are stuck with this problem.
It will help greatly, if you have any idea.


-----Original Message-----
From: Sessa, Romain [mailto:Romain.Sessa@experian.com
<mailto:Romain.Sessa@experian.com> ] 
Sent: 03 October 2011 13:50
To: users@jackrabbit.apache.org
Subject: RE: FineGrainedISMLocking implementation for concurrent access.

Hi and thanks for this quick answer,

We are storing heavy objects in the repository which have plenty of sub
nodes. And we are trying to manage concurrent read/write access to some
of these nodes.  
>From a functional point of view, these nodes are representing business
objects and can be modified (removed) and read at the same time by
different users.
>From a technical aspect, we are some problems when a thread is trying to
read the node as another one is removing it (some exceptions are
Our goal is to put in place a concurrent access managing system. The
idea is to prevent a thread to read and write a node while another one
is editing it.
So if there is any solution to fit with our needs, please advice.



Romain SESSA

-----Original Message-----
From: Jukka Zitting [mailto:jukka.zitting@gmail.com
<mailto:jukka.zitting@gmail.com> ] 
Sent: 03 October 2011 12:55
To: users@jackrabbit.apache.org
Subject: Re: FineGrainedISMLocking implementation for concurrent access.


On Mon, Oct 3, 2011 at 11:41 AM, Sessa, Romain
<Romain.Sessa@experian.com> wrote:
> I'm a developer on a JAVA project that uses Jackrabbit. We need to
> a better management of concurrent access on a node. The LockManager
> isn't enough, among others read access is not forbidden on a locked
> node. We find "FineGrainedISMLocking" interface that seems allow to
> change lock policy for concurrent access. We don't found a simple
> explanation of how to implement it. Have you some development lines
> us ?

FineGrainedISMLocking is a low-level tool that you most likely
shouldn't be using from the application level.

Can you describe your use case in more detail? Without knowing the
exact requirements it's hard to suggest a solution.


Jukka Zitting

Information in this e-mail and any attachments is confidential, and may
not be copied or used by anyone other than the addressee, nor disclosed
to any third party without our permission. There is no intention to
create any legally binding contract or other binding commitment through
the use of this electronic communication unless it is issued in
accordance with the Experian Limited standard terms and conditions of
purchase or other express written agreement between Experian Limited and
the recipient. Although Experian has taken reasonable steps to ensure
that this communication and any attachments are free from computer
virus, you are advised to take your own steps to ensure that they are
actually virus free. 

Companies Act information: Registered name: Experian Limited. Registered
office: Landmark House, Experian Way, NG2 Business Park, Nottingham,
NG80 1ZZ, United Kingdom. Place of registration: England and Wales.
Registered number: 653331

  • Unnamed multipart/alternative (inline, 7-Bit, 0 bytes)
View raw message