Having a single ZEO server handling more than one or two storages is
not usually a good idea. ZEO does not handle each storage in a
separate thread, so you're underusing multiple CPUs if you have them.
Multiple ZEO servers would also spread the open sockets among them.
There could still be a
Hi
In ERP5, the rule is that you should never talk to external systems as
a synchronous response to a user request, and you should avoid, at all
costs, writing to ZODB at the same time as talking to external systems
(or the external system must be able to handle this gracefully).
Of course, it
On Thu, Dec 13, 2012 at 12:11 PM, Leonardo Rochael Almeida
leoroch...@gmail.com wrote:
(or the external system must be able to handle this gracefully).
By this I meant conflict errors, for example SMTP servers posting
INTO Zope can retry sending later in case of error
Hi,
On Mon, Dec 17, 2012 at 10:03 PM, Dylan Jay d...@pretaweb.com wrote:
On 14/12/2012, at 8:32 AM, Jim Fulton j...@zope.com wrote:
On Thu, Dec 13, 2012 at 4:18 PM, Dylan Jay d...@pretaweb.com wrote:
...
I'd never considered that the cache was attached to the db connection rather
than the
This mail from Jim at this list a couple of years ago was stocked full
of nice tips:
https://mail.zope.org/pipermail/zodb-dev/2011-May/014180.html
In particular:
- Yes, use persistent cache. Recent versions are reliable. Make it as
large as resonable (e.g at most the size of your packed
On Tue, Apr 16, 2013 at 5:38 PM, Tres Seaver tsea...@palladion.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[...]
Concrete Proposal
- -
I believe we will need to update ``zodbpickle`` and ``ZDOB`` to allow
for any of the strategies to be applied.
- -
AFAICT, Chistian's problem is that an SQL database would not be such a
good fit, due to the time travel requirement. IIUC, he has to look
up records as they were in the past, including whatever fields they
had in the past, even if they're no longer part of the schema for the
current data. To do
In the projects I was involved, ZODB3 3.11.a3 (not ZODB 4) has hurt more
than it has helped.
In particular, the banishing of standard comparison from BTrees has made
existing data break on an instance where ZODB3 was accidentally upgraded
from 3.10.5 to 3.11a3 by pip 1.4 (i.e. a BTree containing
