jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yusuf Aaji <yusuf.a...@gmail.com>
Subject Re: Multiapps using the same repository
Date Mon, 01 Apr 2013 06:03:41 GMT
Thank you all, using a workspace for each application is really a
good approach, and in this case a shared tomcat resource will be the way to
go.

--
*BR,
Yusuf
* <http://www.gso.org.sa>


On Sun, Mar 31, 2013 at 9:56 AM, Mansour Al Akeel <mansour.alakeel@gmail.com
> wrote:

> I understand that RMI is slower than other mechanism, so if I have a lot of
> interaction with the repository, I would not recommend it.
> You are left with two options, the shared repository or bundled with each
> app.
>
> IMO, it is easier to use one repository if the same users are accessing it.
> You can use a workspace for each application like Christoph suggested, and
> this will save resources consumed by loading multiple repositories in the
> memory.
>
>
>
>
>
> On Sun, Mar 31, 2013 at 2:50 AM, Christoph Läubrich
> <laeubi@googlemail.com>wrote:
>
> > Have you evaluated using different workspaces for different purposes?
> >
> > Am 30.03.2013 10:27, schrieb Yusuf Aaji:
> >
> >  Hi,
> >>
> >> I have multiple spring applications hosted on tomcat7 which uses
> >> jackrabbit
> >> as a content repository, the apps content is not related to each other.
> >> Which is the best option to access jackrabbit in terms of resources
> >> utilization (memory and cpu), safety (repository data corruption or slow
> >> down) and performance :
> >>
> >>     1. Access a single repository using a shared tomcat resource
> >>     2. Access a single repository remotely using RMI
> >>     3. Access separate repository for each app directly as a spring bean
> >>
> >> Those apps are developed in house so monitoring for correct memory usage
> >> and profiling is also a requirement, so which option better suits my
> >> requirements.
> >>
> >> --
> >> *BR,
> >> Yusuf
> >> *<http://www.gso.org.sa>
> >>
> >>
> >>
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message