In repositories.xml, you can specify a mapping between a workspace/
repo name (the name used in magnolia) and an actually repository/
workspace configuration.
Now it's entirely dependent on how the underlying repository reacts to
that - it will probably not work with the default JR persistence
managers and magnolia provider, but maybe with a remote provider ? -
and I can't guarantee that this can even work at all without proper
clustering, but that's just the general idea.
You'll probably need clustering, but the idea is that you don't
necessarily need to cluster the whole of your repository if not needed.
I'm just throwing ideas there, no direct working solutions I'm afraid.
Maybe someone else can shed some light on the status of clustering
with Jackrabbit, but afaik, it still as some quirks that make it not
viable as a general solution for us.
-g
On Oct 22, 2008, at 2:50 PM, Leviter wrote:
Sharing a workspace? Is this possible? How do you define this?
Could you please elaborate a bit about this since it sound like a
solution
which is workable for us.
Any links with more info are also welcome....
-- Marcel
Magnolia - User mailing list-2 wrote:
The real solution would be to either share the one specific workspace
between your public instances, or get clustering to work for your
public instances.
-g
On Oct 22, 2008, at 12:53 PM, Leviter wrote:
Hi,
I'm currently working on a website in which there is some content
generated
by users. In this case the user can store some of his profile. He
then
receives a link via email with a link which enables him to access
the
profile instantly.
The main problem I'm having is because of the architecture... the
environment on which this occurs consists of two public instances
(preceded
by a load balancer). When a user stores his profile it will exists
only on
one public instance. The next time he wants to access the profile it
is not
guaranteed he will be on the same server as the one he stored his
profile
on.
What is the usual/common/best way to deal with this kind of
problems?
I can think of the following solutions:
1) Store the profile on the authoring server and publish it using an
automatic workflow
2) Store it on one public server and sync it to the other
3) Store the profile in a custom database and access this from both
public
servers
Choice number 3 is the most easy one, but then we cannot use the
user
interface of Magnolia to access the profile anymore since it will
not be
stored in the JCR anymore.
For the other 2 options... I have no idea if and (absolutely no
idea) how to
implement this.
Can someone give me some pointers/directions/ideas on how to solve
such an
issue?
--
View this message in context:
http://www.nabble.com/Sharing-data-over-public-instances-tp20108329p20108329.html
Sent from the Magnolia - User mailing list archive at Nabble.com.
----------------------------------------------------------------
for list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
----------------------------------------------------------------
----------------------------------------------------------------
for list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
----------------------------------------------------------------
--
View this message in context:
http://www.nabble.com/Sharing-data-over-public-instances-tp20108329p20110028.html
Sent from the Magnolia - User mailing list archive at Nabble.com.
----------------------------------------------------------------
for list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
----------------------------------------------------------------
----------------------------------------------------------------
for list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
----------------------------------------------------------------
