Synchronize block in BindableRepositoryFactory

[ksingh <ks...@responsys.com>]

Hi,
We are using Jackrabbit in our environment where we have multi-tenancy. We
are supporting multi-tenancy by having a separate repository per customer. I
noticed that every time we start one repository, it blocks the call and no
other repository can be started or stopped during that time. Specially the
time when it needs to build indexes for the repository, then the starting
takes very long. I was looking into the code and I found that there are
synchronization blocks in the BindableRepositoryFactory class in the
getObjectInstance() and removeReference() methods which are used when trying
to get a repository instance or remove it from the jndi context
respectively. The synchronization block is locking on the whole cache
instance hence blocking any other thread accessing the same cache even if it
is trying to get a different repository instance

1. It makes sense to have this block if all the requests are for the same
repository instance (one reference key) so that all the requests for one
repository are serialized and they all do not try to start it if not already
there. But blocking requests if they are for different repositories doesn't
make sense. Is there a good reason why we have this?

2. It would not be an issue if starting of a repository is very quick, but
since getting a repository instance also  builds the index if missing, it
can take very long. So is there a way to decouple these two activities so
that starting a repository, only gets the instance and is very quick and one
can invoke the separate method to build the index for a repository, if there
is such need?

It will be helpful to know if other people have also run onto this and have
any solution for this situation.

Thanks
Kiran





--
View this message in context: http://jackrabbit.510166.n4.nabble.com/Synchronize-block-in-BindableRepositoryFactory-tp4659901.html
Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.

Re: Synchronize block in BindableRepositoryFactory

[Jukka Zitting <ju...@gmail.com>]

Hi Kiran,

On Tue, Nov 12, 2013 at 2:05 PM, ksingh <ks...@responsys.com> wrote:
> 1. It makes sense to have this block if all the requests are for the same
> repository instance (one reference key) so that all the requests for one
> repository are serialized and they all do not try to start it if not already
> there. But blocking requests if they are for different repositories doesn't
> make sense. Is there a good reason why we have this?

The synchronization is required to prevent concurrent modification of
the cache map.

> 2. It would not be an issue if starting of a repository is very quick, but
> since getting a repository instance also  builds the index if missing, it
> can take very long. So is there a way to decouple these two activities so
> that starting a repository, only gets the instance and is very quick and one
> can invoke the separate method to build the index for a repository, if there
> is such need?

It seems like the best way to achieve that would be to call the
BindableRepository.init() method lazily when the repository is first
accessed instead of directly in the constructor.

You may want to file an improvement request [1] for that? Even better
if you can contribute a patch for changing the relevant code.

[1] https://issues.apache.org/jira/browse/JCR

BR,

Jukka Zitting