> Yes, I'm aware of Magnolia, but I'm not yet familiar with it. Ok, as far as Jackrabiit is concerned, each "instance" of Magnolia contains four Jackrabbit repositories (it uses them for different things, only one of them contains the main user content). A single installation of Magnolia consists of at least two instances of Magnolia - one "private" and one or more "public" instances.
There's a "private" Magnolia instance (with 4 repositories), and this were people do all their editing of the data content. Once they are happy with what they've written, they hit the big button "publish". Pressing "publish" causes Magnolia to log in to each "public" instance in turn and upload the new data. If someone changes a username/password on a "public" server without matching that change to the private server, everything breaks. This results in scalable read-performance as you can just keep throwing more servers at the problem, each of which has all the data it needs on its local disk, and use standard tomcat / web clustering to distribute the load. The downside is that write-performance is slow, clunky and (last time I looked) failed silently. The other issue is that Magnolia doesn't support any other method of JCR usage other than embedding the 4 repositories within itself - Magnolia uses unauthenticated access to its repositories, hence you can't afford to open up access outside the WebApp without compromising security - no JCR-RMI etc. > IIUC this means that the private server has to be accessed > explicitely to execute write operations? Yes. > Is there an automatic failover mechanism, i.e. if the private > server goes down, a backup private server could take over > this responsibility (incl. session failover)? I don't believe so. Magnolia seems to have been designed with website publishing in mind, hence an inability to edit data until IT staff fix an issue isn't a big deal (whereas the inability of the general public to view the corporate website would be a big deal). > OK, thanks for this hint as well. But our customer > explicitely prefers a complete open source solution. I can understand that. I believe it's always useful to have a "just pour money at it" solution in reserve in case a more clever solution fails to meet expectations. Of course, that's only viable if your income from whatever you're doing scales with performance demand. Once things take off, and after you've bought yourself a huge mansion and a ferrari from your profits, paying for a commercial JCR should be pocket coinage :-) Until then, we'll all have to try to squeeze as much performance out of Jackrabbit as we can. _____________________________________________________________________ This e-mail has been scanned for viruses by Verizon Business Internet Managed Scanning Services - powered by MessageLabs. For further information visit http://www.mci.com
