[opencms-dev] Can different installations of OpenCms connect to the same db schema?

Achim Westermann achim.westermann at questico.de
Thu Jan 28 19:02:05 CET 2010 

Hi Shency,

you also had to ensure that content from /sites/contentset_X is only served from the very same server (because of flex caching) -> No 
clustering.

Regardless of the fact that I don't understand why you would use a setup with two OpenCms instances that share the same database but actions 
would be taken to ensure that no data is shared (and in this case I'd rather recommend to use two databases ;-)) you also had to ensure that 
content from /sites/contentset_X will only be serverd from the exact very server: No appserver clustering because of the flexcache allowed.

HTH,

Achim



Shency Revindran wrote:
> Hi Jordi/Achim,
> 
> Jordi, That is really useful information for me! Thanks a lot for that.
> 
> Now considering all your points- (May be stupid, please forgive me - I am too new to opencms) 
> 
> If we make sure that
> 
> 	1) opencms instance_X is dedicated for '/sites/contentset_X'. 
> 	 (I.e., admin console users for this instance will ONLY access 	'/sites/contentset_X'-	using restricted user privileges. And this 	instance of web application will ONLY serve request for contents under 	'/sites/contentset_X')
> 
> 	AND
> 
> 	2) module change always happens at one opencms instance (keeping all 	   other opencms instance shutdown during that period)
> 
> -> Here, is it right to assume that indexes/flexcache/locks won't create issues across multiple opencms instances as they work on different sites? Or Am I completely wrong here?
> 
> Thanks,
> Shency
> 
> -----Original Message-----
> From: opencms-dev-bounces at opencms.org [mailto:opencms-dev-bounces at opencms.org] On Behalf Of Achim Westermann
> Sent: 28 January 2010 13:23
> To: The OpenCms mailing list
> Subject: Re: [opencms-dev] Can different installations of OpenCms connect to the same db schema?
> 
> Hi Jordi,
> 
> that's a good description about the functionality that has to be there for clustering OpenCms! And yes: The static export is quite hard, as 
> publishing an exportable resource has to delete the local exported version as well as the versions on the cluster slaves. Some rsync might 
> do the Job. But with a remarkable delay or a remarkable workload for polling while the ocee cluster would actively propagate the action to 
> do to the slaves. Also the solution to nmount the same disk for both systems adds another point of failure / performance loss and somehow 
> transforms the solution to a "virtual Cluster".
> 
> kind regards,
> 
> Achim
> 
> Jordi Martí wrote:
>> Shency, Achim,
>>
>> I'm one of those people Achim talks about, that have tried endlessly to 
>> make two separated instances of opencms work against the same db. I 
>> completetly agree with Achim that IT WORTHS THE MONEY (but I never tried).
>>
>> These are four key aspects I have being fighting against (I wrote in 
>> this list about it time ago). This is based on Opencms 6.2.3 (where I 
>> have two opencms against the same database):
>>
>>      - Indexes: indexes are built in filesystem. If one instance indexes 
>> a file, the other one won't do it, or that's what experience tells me. 
>> You should manually reindex in both machines through a external process.
>>      - FlexCache: if publishing happens in one machine, the other one 
>> will not know that a page has been published, and cache won't be 
>> invalidated. That's why I generally use a timeout based cache (cache 
>> property => "timeout=10").
>>      - Config files: for example, if you import a module in one machine, 
>> the other file "opencms-modules.xml" in the other machine won't be 
>> modified. You could rsync both files or mount that directory or 
>> something like that.  There's no problem with filesystem created JSP and 
>> images, because if one instance doesn't have it, it creates in on the 
>> fly, so there's no problem.
>>      - Workplace Locks: locks are built-in memory, not database. If you 
>> use multiple users on same files, it can affect you, and I don't have a 
>> workaround,.
>>
>> I don't use static export, so I'm not able to study how it affects 
>> static export further,...
>>
>> HIH,
>>
>> Jordi
>>
>>
>>
>> El 28/01/2010 13:28, Achim Westermann escribió:
>>> Hi Shency,
>>>
>>> the cluster module is definetely worth the money. And I am not saying this because I am a former member of Alkacon but because I've seen
>>> some installations where they tried to hack their own cluster functionalities with rsync, cronjobs,.... until they found out that there are
>>> more issues (e.g. caching) and then added another script, another request handler... what a waste of money if you count the time spent
>>> internally.
>>>
>>> cheers,
>>>
>>> Achim
>>>
>>> Shency Revindran wrote:
>>>    
>>>> Hi Achim,
>>>>
>>>> Thank you very much for your reply.
>>>> I am going through the ocee documentation to see how helpful it can be in our case.
>>>>
>>>> Thanks,
>>>> Shency
>>>>
>>>> -----Original Message-----
>>>> From: opencms-dev-bounces at opencms.org [mailto:opencms-dev-bounces at opencms.org] On Behalf Of Achim Westermann
>>>> Sent: 27 January 2010 13:49
>>>> To: The OpenCms mailing list
>>>> Subject: Re: [opencms-dev] Can different installations of OpenCms connect to the same db schema?
>>>>
>>>> Hi Shency,
>>>>
>>>> regarding point 2: That is not possible I think. One problem is that caches are cleared inside the webapp when something is published. The
>>>> other opencms instance would not know it. There must not be more than one workplace log in for the same database
>>>> If you try to scale up your architecture consider using ocee cluster to connect several opencms instances. The database could use ocee
>>>> replication or mysql cluster.
>>>>
>>>> kind regards,
>>>>
>>>> Achim
>>>>
>>>> shency wrote:
>>>>      
>>>>> Hi All,
>>>>>
>>>>> We have an OpenCms 6 application.
>>>>>
>>>>> Currently there exist multiple installations (using sites/default) for
>>>>> different brands, connecting to separate db schema. Now we are thinking of
>>>>> using single db schema by using separate sites for each brand (i.e.,
>>>>> sites/brandA, sites/brandB etc.)
>>>>>
>>>>> I can see two options to do this
>>>>>
>>>>> 1) Have a single installation connecting to common db schema and keep the
>>>>> content under separate sites (i.e., sites/brandA, sites/brandB etc.) for
>>>>> each brands. As per the opencms documentation, this is supported.
>>>>>
>>>>> 2) Here is my Qn, Is it possible to keep multiple installation of openCms,
>>>>> each using its on separate sites for content (i.e., sites/brandA,
>>>>> sites/brandB etc.) and connect to the same underlying opencms db schema? If
>>>>> yes, does the openCms admin console behave consistently across the
>>>>> installations to support concurrent content customisation of each site (off
>>>>> course with controlled user privileges)
>>>>>
>>>>> Please let me know If my description is confusing, so that I will try to be
>>>>> more clear
>>>>> Thanks in advance for help in this regard,
>>>>> Shency
>>>>>        
>>>> _______________________________________________
>>>> This mail is sent to you from the opencms-dev mailing list
>>>> To change your list options, or to unsubscribe from the list, please visit
>>>> http://lists.opencms.org/mailman/listinfo/opencms-dev
>>>>
>>>> ______________________________________________________________________
>>>> This email has been scanned by the MessageLabs Email Security System.
>>>> For more information please visit http://www.messagelabs.com/email
>>>> ______________________________________________________________________
>>>>
>>>> Please note, we have moved. Our new address is Monitise plc, Warnford Court, 29 Throgmorton Street, London EC2N 2AT
>>>>
>>>> This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying, disclosure or taking of any action in reliance upon it by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy.
>>>>
>>>> The Monitise group comprises: Monitise plc (Reg. No. 6011822), Monitise Group Limited (Reg. No. 5590897), Monitise International Limited (Reg. No. 5556711), Monilink Limited (Reg. No. 4831976) and Monitise Business Solutions Limited (Reg. No. 5814266). These companies are registered in England and Wales and their registered office address is: Warnford Court, 29 Throgmorton Street, London, EC2N 2AT United Kingdom.
>>>>
>>>> _______________________________________________
>>>> This mail is sent to you from the opencms-dev mailing list
>>>> To change your list options, or to unsubscribe from the list, please visit
>>>> http://lists.opencms.org/mailman/listinfo/opencms-dev
>>>>
>>>>      
>>> _______________________________________________
>>> This mail is sent to you from the opencms-dev mailing list
>>> To change your list options, or to unsubscribe from the list, please visit
>>> http://lists.opencms.org/mailman/listinfo/opencms-dev
>>>
>>>    
>>
>> _______________________________________________
>> This mail is sent to you from the opencms-dev mailing list
>> To change your list options, or to unsubscribe from the list, please visit
>> http://lists.opencms.org/mailman/listinfo/opencms-dev
>>
> 
> 
> _______________________________________________
> This mail is sent to you from the opencms-dev mailing list
> To change your list options, or to unsubscribe from the list, please visit
> http://lists.opencms.org/mailman/listinfo/opencms-dev
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________
> 
> _______________________________________________
> This mail is sent to you from the opencms-dev mailing list
> To change your list options, or to unsubscribe from the list, please visit
> http://lists.opencms.org/mailman/listinfo/opencms-dev
>

More information about the opencms-dev mailing list