Re: [ZODB-Dev] ConflictErrors won't clear

2005-04-15 Thread Chris Withers
Christian Robottom Reis wrote:
On Fri, Apr 15, 2005 at 12:57:07PM +0100, Chris Withers wrote:
Okay, where in the above should I be calling sync()?
Where do I get sync from? get_transaction() doesn't have a synch attribute..

On the Connection, of course wink
And how do I get hold of the connection? Is that the official way?
Does this change if I have several storages mounted with the stuff that 
ships with Zope 2.7?

cheers,
Chris
--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list  -  ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev


Re: [ZODB-Dev] ConflictErrors won't clear

2005-04-15 Thread Jeremy Hylton
On 4/15/05, Chris Withers [EMAIL PROTECTED] wrote:
 Jeremy Hylton wrote:
 
  It's mentioned in the documentation -- see section 3.4 ZEO programming
  notes -- and it's been discussed on this list many, many times.
 
 Where are these notes?

In the ZODB  ZEO programming guide that's packaged with ZODB and
available in the Wiki.  Perhaps you've read it before?

  It sounds like the simplest approach for your application is to do
  like Zope and start a separate thread that runs an asyncore mainloop.
  Then your application threads will see updates when the commit and
  abort transactions, just like the would in Zope.
 
 I'd really prefer not to do that unless absolutely necessary:
 http://mail.zope.org/pipermail/zodb-dev/2004-June/007554.html

It sounds like the answer here it so avoid fork, rather than asyncore.
 If you don't run an asyncore mainloop, you'll be responsible for
manually sync-ing all the storages/connections that asyncore would
handle automatically.

Jeremy
___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/

ZODB-Dev mailing list  -  ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev


[ZODB-Dev] ConflictErrors won't clear

2005-04-14 Thread Chris Withers
Hi there,
I have a non-zope zeo client that pumps data into a storage server for 
later consumption by a zope zeo client. Everything is Zope 2.7.5.

The non-zope client has logic that looks roughly like:
for work in queue:
  try:
get_transaction().begin()
# do work, change zodb objects, etc
get_transaction().commit()
  except ConflictError:
get_transaction().abort()
queue.append(work)

  except:
get_transaction().abort()
Does anything look amiss there?
The reason I ask is that it works fine, unless someone changes something 
 via the zope zeo client resulting in a conflict error on the non-zope 
zeo client. When that happens, the work where the conflict occurs gets 
put back in the queue, but seems to conflict again next time round, even 
though the change on the zope zeo client is long since committed and 
passed. The work effectively gets stuck in an endless loop of being 
retried and then conflicterror'ing :-(

Any ideas why that could be?
cheers,
Chris
--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list  -  ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev


Re: [ZODB-Dev] ConflictErrors won't clear

2005-04-14 Thread Florent Guillaume
I had a problem like that, and I had to explicitely sync() the
connection before begin(), I think.

Florent

Chris Withers  [EMAIL PROTECTED] wrote:
 Hi there,
 
 I have a non-zope zeo client that pumps data into a storage server for 
 later consumption by a zope zeo client. Everything is Zope 2.7.5.
 
 The non-zope client has logic that looks roughly like:
 
 for work in queue:
try:
 
  get_transaction().begin()
 
  # do work, change zodb objects, etc
 
  get_transaction().commit()
 
except ConflictError:
 
  get_transaction().abort()
 
  queue.append(work)
   
except:
 
  get_transaction().abort()
 
 Does anything look amiss there?
 
 The reason I ask is that it works fine, unless someone changes something 
   via the zope zeo client resulting in a conflict error on the non-zope 
 zeo client. When that happens, the work where the conflict occurs gets 
 put back in the queue, but seems to conflict again next time round, even 
 though the change on the zope zeo client is long since committed and 
 passed. The work effectively gets stuck in an endless loop of being 
 retried and then conflicterror'ing :-(
 
 Any ideas why that could be?
 
 cheers,
 
 Chris
 
 -- 
 Simplistix - Content Management, Zope  Python Consulting
 - http://www.simplistix.co.uk
 ___
 For more information about ZODB, see the ZODB Wiki:
 http://www.zope.org/Wikis/ZODB/
 
 ZODB-Dev mailing list  -  ZODB-Dev@zope.org
 http://mail.zope.org/mailman/listinfo/zodb-dev
 


-- 
Florent Guillaume, Nuxeo (Paris, France)   CTO, Director of RD
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]
___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/

ZODB-Dev mailing list  -  ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev