[Grok-dev] Grok-dev post from mdb036 at googlemail.com requires approval

[Mike Bell]

I've tried to reproduce the behaviour in a simple test app but I haven't had
any luck yet.  I'm not sure exactly what pattern of requests produces the
failure in the real app, but I'll add some debugging trace to try and work
it out.

Cheers,
Mike

On 2 February 2010 12:33, Sebastian Ware <sebastian at urbantalk.se> wrote:

> I allways recomened setting a breakpoint and stepping through the code. A
> lot of Grok stuff has explained itself in interactive sessions.
>
> Mvh Sebastian
> 0707- 577 858
>
> http://www.urbantalk.se
>
>
>
>
> 2 feb 2010 kl. 12.40 skrev Mike Bell:
>
>
>  Hi Sebastian,
>>
>> Thanks for the reply.
>>
>> I'm not interfacing with MySQL at all - for this project I am using only
>> the ZODB to store data.
>>
>> I'm fairly confident that what happens is the object (subclass of
>> grok.Model) is committed to the database in the state that it was in when it
>> was first added to a Container.  I don't think any other changes (to that
>> object or other objects) are committed at all.  I will try and write a
>> script that reproduces the problem this evening.
>>
>> Cheers,
>> Mike
>>
>> 2010/2/2 Sebastian Ware <sebastian at urbantalk.se>
>> If the request fails all changes should revert. How are you interfacing
>> MySQL? If you are doing this through your own code, that could explain why
>> db-writes don't honor the transaction rollback.
>>
>> Mvh Sebastian
>>
>>
>> 2 feb 2010 kl. 00.47 skrev grok-dev-owner at zope.org:
>>
>> As list administrator, your authorization is requested for the
>> following mailing list posting:
>>
>>  List:    Grok-dev at zope.org
>>  From:    mdb036 at googlemail.com
>>  Subject: Transactions and competing writes/reads warnings
>>  Reason:  Post to moderated list
>>
>> At your convenience, visit:
>>
>>  https://mail.zope.org/mailman/admindb/grok-dev
>>
>> to approve or deny the request.
>>
>> Från: Mike Bell <mdb036 at googlemail.com>
>> Datum: ti 2 feb 2010 00.47.15 GMT+01:00
>> Till: grok-dev at zope.org
>> Ämne: Transactions and competing writes/reads warnings
>>
>>
>> Hi,
>>
>> I'm new to grok and zope, but learning fast - it looks like a neat
>> environment for putting together apps quickly and fairly cleanly (compared
>> to php & mysql, which I've been using up til now).  I've created an app
>> (it's going to be a facebook game) that seems to generally be working fairly
>> well, but today I hit this warning from zope:
>>
>> 2010-02-01T13:35:01 WARNING ZopePublication Competing writes/reads at
>> /iridium/galaxy: database conflict error (oid 0x1446, class
>> iridium.player.Player)
>>
>> After this it appears that some but not all of the changes made by a
>> single request have been committed to Zope, leaving an object in an
>> inconsistent state.  It looks like the inconsistent object was created
>> during the request that failed due to the warning, but a modification made
>> to that object during processing that same request was not committed to the
>> database.
>>
>> My understanding was that all changes made in a single HTTP request are
>> committed as a single transaction, but that doesn't seem to have worked
>> here.  Do conflicts like this need to be handled in a special way - if so,
>> how do I catch them?  I can't seem to find any details about how grok uses
>> transactions in the documentation.
>>
>> Any hints would be much appreciated!
>>
>> Thanks,
>> Mike
>>
>>
>>
>> Från: grok-dev-request at zope.org
>> Ämne: confirm 11cb368a852a113c8f27fc0f7178e213afc82422
>>
>>
>> If you reply to this message, keeping the Subject: header intact,
>> Mailman will discard the held message.  Do this if the message is
>> spam.  If you reply to this message and include an Approved: header
>> with the list password in it, the message will be approved for posting
>> to the list.  The Approved: header can also appear in the first line
>> of the body of the reply.
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.zope.org/pipermail/grok-dev/attachments/20100203/df1b95b5/attachment.html