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