On Sun, 2008-03-23 at 11:38 -0400, Sean Allen wrote: > Can that be wrapped in a transaction so that if something goes wrong > with customer creation, the order gets rolled back as well? > > Or put higher level, do transactions only work within a single folder > or across folders?
You can modify as many objects as you like in a transaction. Have you read the ZODB/ZEO programming guide yet? http://www.zope.org/Wikis/ZODB/guide/zodb.html > >>> There is another good reason - it makes a lot more sense to > >>> distribute > >>> object creation to different containers in the ZODB to avoid write > >>> conflict errors. > >> > >> I think I understand this but can you elaborate? > >> > >> By 'distribute object creation to different containers' do you mean > >> store each > >> object in own folders? > > > > No that would lead to an unnecessary proliferation of folders and it > > wouldn't actually remove conflict errors. > > > > Conflicts errors occur when two concurrent transactions modify the > > same > > attribute. When you are putting objects in a folder you are > > essentially > > modifying the same attribute (unless you are using a btree). A good > > application design strategy for the ZODB is to ensure that concurrent > > transactions are modifying attributes on different objects. If you are > > putting all your orders in one folder you are increasing the chances > > of > > conflict errors. > > > > If you dont put all orders in a single folder, when it comes time to > search orders, how would you know where to find? > > Do you sequentially search the multiple folders for a given object? No. You index the order attributes that you want to search on and perform a search on the indexes. Have a look at zc.index and zc.catalog http://svn.zope.org/zc.index/ http://svn.zope.org/zc.catalog/ I think you will also benefit a lot by looking at Zope as development platform. Have a look at the Zope3Book: http://wiki.zope.org/zope3/Zope3Book > > > Like I mentioned above you could use a btree folder since it has a > > fairly good conflict resolution strategy. But given a high enough > > insertion rate even a btree will not protect you against conflict > > errors. I would recommend you create orders inside a btree-based order > > folder inside each customer. This will significantly reduce the > > likeliness of conflict errors. > > > > So if this occurs, you get an exception ( basically optimistic locking ) > which you then deal with on a higher level in your application? Yes. > > The most valuable resource is the mailing list. Unfortunately > nobody > > has > > documented their experience elsewhere before. > > > > Well, if I go with zeo/zodb and python, I'll be sure to document the > entire thing. Cool! We really need that! -- Roché Compaan Upfront Systems http://www.upfrontsystems.co.za _______________________________________________ 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
