On Fri, Sep 19, 2008 at 4:15 PM, Tres Seaver <[EMAIL PROTECTED]> wrote:
> Hash: SHA1
> Marco Bizzarri wrote:
>> Thanks for the suggestion, Tres, I'm trying it right now.
>> I think this could be responsible for the problem I had a few months
>> ago, under the name: "Asking advice on a Zope "stuck" (or: what did I
>> do wrong?)"
>> Do you think there will be some sort of "general" solution to the
>> problem? I mean, the problem is actually that there are some objects
>> which should not be ghostified, or am I wrong?
> There are two problems here:
>  - Some objects need to be able to mark themselves as "sticky" for
>   at least the duration of a transaction;  my workaround is hackish,
>   because if you omit the 'del conn._p_changed' it causes the object
>   to be written needlessly;  likewise, if the conn object *is* actually
>   written to during the transaction, those changes will be discarded.

I'm afraid the workaround is not working for me; I've modified the
test as follows:

class DoubleTransactionTest(ZopeTestCase.ZopeTestCase):

   def _add_big_image(self, value, data):
       Image.manage_addFile(self.app, "f%06s" % value, data , "a title")

   def test_showdouble(self):
       manage_addZPsycopgConnection(self.app, "db_connection", "",
"host=localhost user=postgres dbname=template1")
       self.app._setObject('sql', SQL.SQL("sql", "", "db_connection",
"", "select * from pg_tables"))
       self.app.db_connection._p_changed = 1
       data =  "*" * (1 << 20)
       for x in range(1000):
           self._add_big_image(x, data)
           print "Added %s " % x

But I can still see two transactions (I'm not bothering about removing
the _p_changed flag, because this is a one shot test, just to see if
it works... maybe I'm putting this in the wrong place).

>  - We need a way to keep the Pdata objects from evicting "precious"
>   objects;  ideally, Pdata instances would never be added to the cache
>   at all.  I worked a bit on a spike in which the Pdata iterator part
>   would use a one-off connection with a zero-sized cache, but got
>   stuck somewhere;  maybe somebody else can make it work.

I would be glad to help, but my current understanding on "inner" Zope
are not good enough (and my "free" time is even less ;))

> Tres.
> - --

Do you mind if I forward this to ML?

Marco Bizzarri
Zope maillist  -  Zope@zope.org
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-dev )

Reply via email to