Corey, ZODB is very stable. It's fast, and it's very transparent. It serves web apps very well. With ZEO, it becomes compelling for distribution of logic and data. But it's not particularly well-equipped to handle high-write situations in any configuration. If your app will have many concurrent users all wishing to write to the same objects at the same time, it may be wise to look into a relational datastore, many of which offer record-level locking instead of the optimistic write-collision detection strategy used by the ZODB. Although I've not used it, I believe Phillip Eby's ZPatterns product aims to facilitate object-relational mapping in these sorts of cases, and it apparently allows you to prototype using the ZODB and move to other data stores later without application logic changes. If you're on the edge of thinking this may not be a requirement, you'd be wise to get comfortable with the nitty-gritty of how the ZODB works so you can design your objects to be well-behaved in modest concurrent-write situations. Looking at the ZODB UML model in the Developer section of Zope.org is a good start. If you search for ZODB on Google, probably the first thing that will come up is Jim's paper on the ZODB for the 2000 Python conference, which is another good place to start. ----- Original Message ----- From: <corey@axcelerant.com> To: <zope@zope.org> Sent: Saturday, December 23, 2000 3:13 PM Subject: [Zope] ZODB robustness

Yo!

Hey, I got a few questions and could use the advice from some of you experts out there.

First off, a quick background. I'm in the current design and analysis stage of a major new project. What I'm doing is a complete re-write of a venerable Operational Support System - essentially, an n-tier framework that will be the ultimate, back-bone engine ultimately running the whole company. Mission Critical comes to mind...

My vision is to implement this thing entirely, from start to finish, thoroughly in an object-oriented model. This is easy as far as the web-application ( our front-end user interface ) is concerned, of course, by using Zope. However, in order to see a pervasive object-orientd design through and through - I'd also like to store all *data* as objects, within an Object Database as well -- rather than the more traditional means of using an RDBMS as the data-store and composing and decomposing complex objects into tables... Yuck.

Now, as a ( rather pleasant ) side-affect of choosing Zope as our Web Application Server - it looks like Python will be the choosen language that we'll be using to construct this OSS in. Which leaves every OODB *I'm* aware of out ( they all only support C++, Java and/or Smalltalk ) -- except, that is, for ZODB.

So there it is. Can a whole company confidently rely on ZODB as a robust ( I know it's scalable, with ZEO ) OODB solution for a large, highly-active, mission-critical, highly-available, enterprise Operational Support System infrastructure? Storing and serving thousands of objects? For added reliability, I've looked into utilizing one of the custom ZODB storage types - namely, OracleStorage looks like the ticket - rather than the standard FileStorage Data.fs.

So please, tell me - am I totally wacked? Crazy? Stark-raving Mad? Should I just use Zope and stick with Oracle rdbms for the data store, or is ZODB truly a viable and robust OODB? I really appreciate any and all comments, advice or rotten vegetables, thanks!

Beers,

Corey

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