> If you need sequential numbers, cache them in a class var in the image.
> If you have multiple Squeak images generating customers there are
> several strategies you could use: 1) cache small ranges through a
> reservation system (each image reserves a subrange of the primary keys
> requiring a DB transaction only to reserve the next range or give up
> unused reserved values), 2) one image serves as a "customer number
> server" and the other images communicate with it through a socket (you
> can get rid of the overhead of GOODS this way).  Oracle has an option 
> to
> use the first strategy...otherwise sequence number generation requires 
> a
> DB round trip.  The first option has the distinct disadvantage of 
> having
> possible holes (unused #'s) or non-time sequential numbering.  This
> doesn't work for invoicing, for example, but might be fine for customer
> numbers.  Finally, if you don't need numbers (or sequential numbers)
> then use UUID's.  Cees has already mentioned this.

Interesting. Will look further into this.

> Most of this is not a problem with GOODS.  I don't see how your problem
> scales with the number of customers. The operations you described can 
> be
> done reasonably quickly -- O(nlogn) or better -- even for an 
> arbitrarily
> large number of customers with careful indexing for searches.  The
> roundtrips for sequence number retrieval/updates doesn't change when 
> you
> have one customer or a billion.  Based on your benchmarks it seems like
> 0.2 seconds per round trip, no problem for a web app.  What would 
> become
> a problem is, for example, doing bulk updates or reporting on orders or
> customers.  Normally only "open orders" or "recent orders" need to be
> reported which suggests that you keep indices on these so you don't 
> have
> to try to loop over all of them.  Maintenance of these indices becomes 
> a
> headache if you have too many of them though.  You'll also get in real
> trouble if you need ad hoc reports (ones where you didn't anticipate 
> the
> need for an index) on such large numbers of objects.  Also the GOODS
> client caches may cause you memory issues when handling large numbers 
> of
> objects...again, depends on your needs.
>

These are good news. Will try to run some simulations on large data 
sets to see how GOODS behaves.

> My server peaks around 20-30% CPU
> usage (Gentoo linux w/ 2.6.10 kernel).  I run behind an apache server
> proxy (also apache serves absolutely all of my static content including
> images and CSS).

Would love to learn more on how you (and I've seen other people in the 
list recently post similar comments on the REST and Seaside thread) 
have configured Apache to do this for you.

Thanks again,
Daniel Salama