Hi Fabrice,

I think anyone using magnolia in a load-balanced environment with 
user-generated content will come across this problem.
We use a "mixed" approach:

Some content is not that suitable for JCR anyway - things like Votings or 
Raffle-Ticket-Registrations - these are datasets that are best stored in a 
database table, storing them in JCR requires careful planning not to "overload" 
individual nodes with too many children. So we just store this data in a 
separate database, which can be accessible from all public nodes, and can be 
handled "in the standard way" using existing database infrastructure.

Some content is better stored in JCR, for example uploaded content, especially 
images, which can then benefit from the imaging module and magnolia's editing 
features, or  forum or comments content, which can be implemented with 
magnolia's forum and comments modules, which use JCR. For this type of content 
we use a JCR cluster.

Other users (there's discussions in the forum you can search for) seem to 
prefer solutions based on observation and replication. This can be set up with 
minimal effort using magnolia's observation  module, and using the standard 
activation mechanism for replicating the data.

You are correct (I think) that replicating on the underlying DB layer would be 
a bad idea. I'm not sure whether the replication is really cheaper 
operationally than an additional JCR instance. That would be an interesting 
question to answer reliably. Clearly the replication comes with an operational 
cost as well, and there are many tricky situations to consider (how to handle 
failed replications or what to do with data that arrives while the second node 
is down for maintainance, etc...).

Regards from Vienna,

Richard


-----Ursprüngliche Nachricht-----
Von: [email protected] [mailto:[email protected]] 
Im Auftrag von Fabrice Lazzari (via Magnolia Forums)
Gesendet: Donnerstag, 28. Juni 2012 10:28
An: Magnolia User List
Betreff: [magnolia-user] JCR Clustering and user generated data

Hi everybody,

We're currently developing a system where we need to save some user generated 
data in the JCR (Data module). We didn't think about that at the very beginning 
but we now face the problem that our system will be deployed in cluster mode. 
That means we'll have 2 application servers, 2 JCR instances, and of course 2 
data modules !

The problem will come if a user first logs in on the first node, his data are 
then saved in the first JCR data module. If he then comes back in a second 
session and is forwarded to the second app server / data module by the load 
balancer, he'll not get access to his data saved on the first node.

I think a standard solution to this problem is to have the data module 
externally hosted on a third JCR instance, with both app servers using it to 
save the user generated data. Sounds not bad, but the problem is it generates 
more costs on the operating side.

We've imagined it may exist a data replication solution, where the user 
generated data would be replicated from one JCR instance to an other. Probably 
not a good idea to implement it on a pure DB-level since the table structure of 
the JCR is not that readable, but maybe the JCR itself has such a functionality 
? Has someone already experienced something this way ?

Or maybe somebody would have any other idea ?

Thanks in advance !

-- 
Context is everything: 
http://forum.magnolia-cms.com/forum/thread.html?threadId=786bca43-b269-48eb-abe7-8bac1f431653


----------------------------------------------------------------
For list details, see http://www.magnolia-cms.com/community/mailing-lists.html
Alternatively, use our forums: http://forum.magnolia-cms.com/
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------





----------------------------------------------------------------
For list details, see http://www.magnolia-cms.com/community/mailing-lists.html
Alternatively, use our forums: http://forum.magnolia-cms.com/
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------

Reply via email to