Hello Alessandro,
My Answers are inline: -----Ursprüngliche Nachricht----- Von: [email protected] [mailto:[email protected]] Im Auftrag von Alessandro Vergari (via Magnolia Forums) Gesendet: Mittwoch, 02. Mai 2012 10:58 An: Magnolia User List Betreff: [magnolia-user] Re: Magnolia Clustering Thank you Richard, if I don't cluster "config", "mgnlVersion" and "mgnlSystem" workspaces it means I will have separates repository for each node. But I have two istances of Admin Interfaces. When I update a node in config workspace in the first instance of Admin Interface, for example, how do I can align the second instance of Admin Interface ? That's currently not possible. The Authoring instance cannot be clustered. This is because there is no synchronization mechanism in place to handle concurrent updates of magnolia's datastructures, or more generally speaking, no synchronization of user actions between the instances. The results would be very unpredictable. For a workspace like "forum" or "media", having a cluster can work, even between author instances. Even though in theory things could get messed up if editors try to write the same content object at the same time, it won't bring down magnolia, and depending on the number of editors and their usage patterns, collisions of this type can be quite unlikely. So basically you're living with the risk of small scale data corruption problems in order to get functionality you need. What is the persistence manager I should use for the workspaces not clustered ? For workspaces you don't mean to cluster, you don't need to change the configuration. A database-backed persistence manager with file-system based datastore is standard, but it really depends what you want. I should use a distinct DB for each node ( in my case 5 Schema) or the filesystem (the server node filesystem) ? For the cluster, you need to use the *same* database for all the nodes. For the cluster, you need to use a persistence manager and file-system backend that can handle concurrency. For this reason, you can't choose file-system, you have to go for a database. For non-clustered repositories, I would make a separate database for each node. For non-clustered repos you can choose between file-system and database, as you prefer. Are there important aftermath about performaces if I use DB rather than filesystem ? I have seen no reliable figures on this. For cluster you have to use the database anyway. What is the procedure to adopt when I have to update the environment with a new version of my application including new nodes ? I must erase the index and workspace directories ? Or simply I have to insert the repository XML files including only the new nodes in bootstrap folder ? No, you don't need to erase the indices. You *never* need to erase the workspace directories unless you are trying to delete the workspace completely. You only need to delete the indices if there is index corruption, and you are trying to recreate the indices. XML loaded by magnolia into the repository will be automatically indexed. If I include a node already present in bootstrap file, when Magnolia starts, the node already present will be overwrited ? Magnolia has several different types of initialization procedures. The initial bootstrapping only happens *once*, when magnolia is first started, and detects that the repository is new. It sounds like what you want is more of a module initialization. When magnolia detects a new module, the module's initialization is performed, and this can include loading XML content into the repository. The same can be made to happen when a module's version number changes. You can control this process from your module's "VersionHandler", and for example determine whether you prefer to replace existing content, or leave it untouched. Regards from Vienna, Richard Thank you very much Richard. Your informations are very valuable, but they opened to new questions very important for my environment correct operation. Alessandro -- Context is everything: http://forum.magnolia-cms.com/forum/thread.html?threadId=986221b3-2a3b-449c-af9a-a2f8b01d291d ---------------------------------------------------------------- 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]> ----------------------------------------------------------------
