Inline...
Le 27/02/2014 13:31, [email protected] a écrit :
Just my 0.02 here:
My understanding is still that the delegator handling might not be robust
enough on OOTB OFBiz. When it comes to backend access every too often I have
issues to see proper data or even logging in. Respective JIRA is open.
Do you know the Jira number?
I'm surprised by this. Because I have recently worked on a relatively big project (3 Nginx front end servers, 5 web apps servers, 3 Postgres DB
servers of which 2 read only slaves handled by PGPool II) during 2,5 years (based on something near R11.04) and I never experienced any problems when
the DB was correctly settled (happened once that new DBAs broke it)
Jacques
Multiple DB needs to be the solution. Such is also leveraging a depend-nothing
concept better than shared DB. Sharding multiple OFBiz instances to manage the
traffic will be also easier, not speaking about upgradding ti dedicated
instances etc.
Re postgres I feel tenant-level backups into XML using OFBiz on-board tools
might anyways be more efficient. The subset of entities that are populated into
OFBiz by Tenant use are pretty clear.
Regards
Carsten
Gesendet von unterwegs mit BlackBerry® Webmail.
-----Original Message-----
From: Pierre Smits <[email protected]>
Date: Thu, 27 Feb 2014 12:57:54
To: <[email protected]>
Reply-To: [email protected]
Subject: Re: OFBiz Multi-tenancy
Hi all,
Thank you for submitting links to documents related to the subject.
Of course, for each the criteria might vary and weigh differently, and the
options available in current feature set of OFBiz are limited.
But in whole, the cost of operations are key. These cost of operations not
only include the hardware and software cost, but also the effort of
maintaining the environment. While setting up a new tenant is easy, and
maintaining the happy flow (uptime and backup), the crucial factors in this
are the performance of the persistence engine and recovery cost in case of
unexpected data loss.
As many (on the internet) seem to be agreeing on the recovery cost in the
case of a shared database-shared schema approach can be expected to be high
due to the intricacies of the beast as opposed to a 'separate
database-separate schema' setup.
Yes, multiple databases might lead to a performance overhead and higher
maintenance cost, but a side-by-side comparison of the various aspects of
each approach (separate db-separate schema vs shared db-separate schema vs
shared db-shared schema) is something that would surely help in assessing
what would be the best approach in various scenarios.
If that would be available, then a sound roadmap could be devised for this
subject.
Regards,
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
