This is a pretty good idea... the default RAM-based storage that is used
for sessions (TemporaryStorage) tries hard to resist conflicts. It is
also nonundoing and does its own reference counting, so it needn't be
packed unless there it contains cyclic datastructures (there is no UI to
pack the
Yo,
I have been following this thread for quite some time now,
and call me stupid if you must, but why don't you just keep
the data in the session and write it all out when the session
gets cleaned up?
For the original problem (keeping statistics of site usage)
this will be more than enough.
On Fri, 19 Apr 2002 07:54:42 -0400, Paul Everitt <[EMAIL PROTECTED]>
wrote:
>This pattern applies better when you have a lot of document cataloging
>to be done. A separate process can wake up, make a ZEO connection, and
>process the queue. I don't think that indexing documents *has* to be a
Shane Hathaway writes:
>
> The change to transactions seems simple. Another thought: the
> long-lived queue might be committed only when there are regular objects
> to commit *and* a certain amount of time has passed since the last
> commit of the long-lived queue. That might work w
Paul Everitt wrote:
> Let's say we had a queue in Zope. We could asynchronously send changes
> into the queue. Later, based on some policy (e.g. idle time, clock
> ticks, etc.), those changes would be enacted/committed.
>
> Imagine the queue itself is in a different storage, likely
> non-ver
On Fri, 19 Apr 2002 08:18:47 -0400, Chris McDonough <[EMAIL PROTECTED]>
wrote:
>> Storing counter objects *only* in a non-undo storage would be more
>> pleasant if ZODB supported cross-storage object references.
>
>Yup. I don't think this is anywhere on the radar, though...
H. cross-storag
Chris McDonough wrote:
>
> > Storing counter objects *only* in a non-undo storage would be more
> > pleasant if ZODB supported cross-storage object references.
>
> Yup. I don't think this is anywhere on the radar, though...
How hard would they be to add?
cheers,
Chris
_
> A dual mode storage, or simply dual storages?
The former as a long-term goal, the latter as a short-term goal. The
proposal I mentioned would make it easier to build tools that allow you
to mount storages.
> Storing counter objects *only* in a non-undo storage would be more
> pleasant if ZO
On Wed, 17 Apr 2002 23:01:04 -0400, "Chris McDonough"
<[EMAIL PROTECTED]> wrote:
>It would be best to make make a dual-mode undoing and nonundoing storage on
>a per-object basis. But a half step would be to make it easier to use
>mounted storages ala
>http://dev.zope.org/Wikis/DevSite/Proposals/
ForkedStorage, I like it simply for the coolness of the name. :^)
But it sparked a different kind of idea, leveraging a pattern that might
emerge in Zope 3.
Let's say we had a queue in Zope. We could asynchronously send changes
into the queue. Later, based on some policy (e.g. idle time, cl
Ivo van der Wijk writes:
> On Wed, Apr 17, 2002 at 07:54:04AM -0400, Paul Everitt wrote:
> > Let's take the next step and say that you can live with a little
> > volatility in the data. You write an object that caches ten seconds
> > worth of writes. Whenever a write comes in at the over-t
Jeremy Hylton wrote:
>>"CM" == Chris McDonough <[EMAIL PROTECTED]> writes:
>
>
> >> Completely agreed. My disagreement is portraying the counter
> >> problem as impossible with the zodb. I think some people, as
> >> evidenced by some of the responses, are willing to live with the
Jeremy Hylton wrote:
>>"CM" == Chris McDonough <[EMAIL PROTECTED]> writes:
>
>
> >> Completely agreed. My disagreement is portraying the counter
> >> problem as impossible with the zodb. I think some people, as
> >> evidenced by some of the responses, are willing to live with the
> "CM" == Chris McDonough <[EMAIL PROTECTED]> writes:
>> Completely agreed. My disagreement is portraying the counter
>> problem as impossible with the zodb. I think some people, as
>> evidenced by some of the responses, are willing to live with the
>> tradeoffs. Other people will
> That's only if you do it as a property. It doesn't have to be done that
> way. Shane and I discussed a counter that existed as a central
> datastructure. Objects that were being counted would simply have
> methods to increment the count and display the count.
FWIW, this already mostly exists
;s did not
create a ZODB transaction.
Hope this helps
Eric
- Original Message -
From: "Casey Duncan" <[EMAIL PROTECTED]>
To: "Ivo van der Wijk" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, April 16, 2002 10:04 AM
Subject: Re: [Zope
This will kill performance, especially concurrent use of the site. It
will also cause large amounts of database bloat. Do you need real time
numbers, or is a delay (such as 24 hours) acceptable?
If you can stand a delay, another approach would be to write a script
which scans the z2.log file (
Hi,
How bad are per-request transactions in a non-ZEO environment? I.e.
each request on a folder or its subobjects will cause a write transaction
(somewhat like a non-fs counter, but worse as it happens for all subobjects)
And if this is really bad, are there any workarounds except for writing
t
18 matches
Mail list logo
