It’s part of why OpenEdge isn’t a database of choice, even though it’s a great database – tools support was horrid (and I think part of the motivation for the purchase of DataDirect) – better ODBC support.

I just found your post- it was great to re-live some of my time as a presales engineer at ODI in the late 90’s. I fondly recall spending hours selling ObjectStore to customers in Financial Services and pitching our distributed cache architecture. You are right that to call ObjectStore a database was a strategic misstep for sales- reporting and data sharing were two of the biggest objections we would get.

It is great to see ObjectStore is alive and kicking- it remains one of my favorite all time products to have worked with.

Thanks,

Bill

They had not anticipated our architecture, which mapped a huge number of pages independently. So they were using a simple linear search. Guy Hillyer wrote an improvement to Solaris, using skip lists to make the search run in O(log n) time. The hard part was the politics getting Sun to accept our changes to Solaris! We only did this for Solaris, which was then our primary platform. (Maybe it should be done for Linux?)

I suspect that the level of performance degradation you’re talking about doesn’t exist in modern Linux, because things like Electric Fence have to run at least somewhat efficiently. There have occasionally been changes to Linux that make Electric Fence run unusably slowly, but they tend to be short-lived.

As an example, using vim, if I LD_PRELOAD=libefence.so.0.0 vi /usr/share/doc/electric-fence/README.Debian, which is a tiny file, the resulting vi process takes a few seconds to start up and is a little slow (on my 700MHz laptop from the previous millennium), and cat /proc/27158/maps | wc shows that it has 25070 regions mapped. (As compared to 186 regions normally.)

I’m not 100% clear on whether the problem Scott Burson is running into is the same problem ODI ran into; from the kernel Bugzilla bug, it sounds like Linux perhaps deals better with many mmapped regions than with a single mmapped region with pages in many different protection states.

Even though ObjectStore perfomed as advertized, our project failed because 1) the largest servers at the time had relatively small memory footprints and slow 33Mhz processors which led to to slow performance too much paging 2) we added too many fancy features to exploit multiple inheritance and incremental processing in our object model 3) The paying project (an IBM mainframe based on VLSI bipolar chips to replace the 3090) was killed.

The level of design integration we accomplished by using ObjectStore could not be achieved with any other database technology and has not been matched by any CAD vendor.

The Object Design engineers were all top notch people that you could depend on to solve any problem that came up.

I’ve been working exclusively in Java for the last 10 years and wish that Object Design had implemented a native Java Server with the same characteristics as the C++ server. The world needs a robust high performance Java object sharing technology. It’s a shame that the world still has to use SQL and RDBs to store java objects.

A very interesting story indeed. I used to work at a CASE company that was an ODI customer, but our C++ experiment lasted only a few years before we came to our senses and went back to Lisp , so we never really did that much with ObjectStore. And in more recent years I had wondered what had become of it. So it’s nice to hear that it’s still out there.

Oh, about your parenthetical question asking whether Linux has the same problem with kernel memory region table fragmentation that Solaris once had, the answer is yes. See: http://bugzilla.kernel.org/show_bug.cgi?id=5493 As you’ll see at the bottom of that page, I have switched to Solaris to get around that problem. Amusing to know that it was ODI that made that work in Solaris to begin with.

Just stumbled on your blog. This post brings back memories — I was a consultant at Object Design under Guy Morgante and Greg Foudray, Some of my best technical times were with debug builds of ObjectStore running on my laptop while helping store, retrieve. and analyze data from Intel for simulations of their first Pentium chip. I can honestly say that only once since did I ever work with such an overall strong team of engineers. It was also the only product where I had dreams about reading code, mentally running it to see how the memory mapping would work, and re-architecting it.

John S.