Bioperl: RE: On Commercial OODBs for XML

[Lincoln Stein]

As I said in the original letter, my comments on ObjectStore refer to
the Unix version as of 1996.  I have not used the product since then.
I grant that it may have improved in recent years.

Lincoln

Otillar, Robert {~Palo Alto} writes:
 > 	Thanks for a highly informative letter; I appreciate your sharing
 > your experience.
 > 	I have been told a few things about ObjectStore & would appreciate
 > your comments:
 > 
 > *	The WinNT version is a easily usable & trustable product? The WinNT
 > version of Object Store on SGI is 'one revision behind and requires a fair
 > bit of sysadmin knowledge to tune the SGI, but that the NT version is much
 > easier to support & use.
 > *	Major vendors are using ObjectStore; is it as easy & reliable as
 > they claim? NetGenics uses ObjectStore with the C++ engine, coupled with a
 > Java API. This configuration is robust (?), perhaps due to Java's built-in
 > memory-handling rather than C++'s user-controlled memory handling. The
 > NetGenics software team seems quite knowlegable and, in a demo, their
 > product looked well designed and stable.
 > *	How does ObjectStore's reliabliity & usability compare to the
 > alternatives? ObjectStore looks much easier to administrate than
 > Objectivity, given the GUI admin tools on their web-site. I believe I've
 > heard that ObjectStore is easy to administrate on NT, but can't recall a
 > concrete reference guaranteeing this is true.
 > *	Any experience with Objectivity, Poet, or other systems?
 > 
 > 
 > *	Do you have reccommendations on other systems: reliable, easily
 > learned and administrated, reasonably fast persistent object storage & query
 > tool (for use with BioPerl)? 
 > *				se Oracle8's object-relational interface and
 > design 2000 tools. (FYI Oracle 8 on linux is now free to developers <
 > http://technet.oracle.com/ >).
 > 
 > 
 > Thanks,
 > 	Bobby O
 > 
 > > -----Original Message-----
 > > From:	Lincoln Stein [SMTP:lstein@cshl.org]
 > > Sent:	Thursday, January 14, 1999 6:44 AM
 > > To:	Otillar, Robert {~Palo Alto}
 > > Cc:	David J. States; 'vsns-bcd-perl@lists.uni-bielefeld.de'
 > > Subject:	On Commercial OODBs for XML RE: Bioperl: XML/BioPerl
 > > 
 > > Otillar, Robert {~Palo Alto} writes:
 > >  > 
 > >  > 
 > >  > > Is anyone aware of plans on the part of the database organizations to
 > >  > > serve 
 > >  > > XML?
 > >  > > 
 > >  > 		I've been giving thought to XML as representation standard
 > >  > to couple with a persistent storage database for genomic data. I
 > > thought you
 > >  > might be interested in a little of what I've found out about the
 > > commercial
 > >  > OODB products.
 > >  > 
 > >  > 		Object Designs, Inc., (www.odi.com) is in late beta-testing
 > >  > of their Excelon XML database/server, part of the ObjectStore line of
 > >  > products. Of interest:
 > >  > 		ObjectStore has PERL drivers on CPAN. (The supported
 > >  > bindings are in C++ and Java).
 > > 
 > > I had five years of experience writing biological databases with
 > > ObjectStore using the C++ binding, and can state unequivocally that
 > > I'd never do it again.  When a C++ object is persistent, all dangling
 > > references, memory leaks, twice-deallocated pointers, and incompletely
 > > constructed objects are persistent too.  This gives any application
 > > programmer the ability to corrupt the database.  I haven't tried the
 > > Java or Perl drivers; perhaps they're better.
 > > 
 > > ObjectStore is also a real administrative hassle to set up and
 > > maintain.  Getting the system up and running means mastering a slew of
 > > obscure environment variables and strangely-named configuration files.
 > > Unfortunately the voluminous manuals are poorly written and badly
 > > organized.  On the bright side, ObjectStore's help desk is excellent,
 > > and their technical support outstanding.
 > > 
 > > ObjectStore's competitors are right when they warn about scaleability.
 > > ObjectStore is designed around clever uses of the Unix mmap() system
 > > call.  Unfortunately different systems have arbitrary limits on the
 > > amount of disk space that can be mapped in this way.  On SunOS the
 > > limit is hit at about 1 gigabyte (don't know about Solaris).  On IRIX
 > > systems this was 2 gig.  This really hurts.  The limit is extremely
 > > high on 64-bit architectures like Digital Unix/Alpha, but when we
 > > tried to run the appropriate version on alphas, it was too buggy to
 > > use.
 > > 
 > > Lincoln
 > > 
 > > -- 
 > > ========================================================================
 > > Lincoln D. Stein                           Cold Spring Harbor Laboratory
 > > lstein@cshl.org			                  Cold Spring
 > > Harbor, NY
 > > ========================================================================
 > > =========== Bioperl Project Mailing List Message Footer =======
 > > Project URL: http://bio.perl.org/
 > > For info about how to (un)subscribe, where messages are archived, etc:
 > > http://www.techfak.uni-bielefeld.de/bcd/Perl/Bio/vsns-bcd-perl.html
 > > ====================================================================
 > =========== Bioperl Project Mailing List Message Footer =======
 > Project URL: http://bio.perl.org/
 > For info about how to (un)subscribe, where messages are archived, etc:
 > http://www.techfak.uni-bielefeld.de/bcd/Perl/Bio/vsns-bcd-perl.html
 > ====================================================================
-- 
========================================================================
Lincoln D. Stein                           Cold Spring Harbor Laboratory
lstein@cshl.org			                  Cold Spring Harbor, NY
========================================================================
=========== Bioperl Project Mailing List Message Footer =======
Project URL: http://bio.perl.org/
For info about how to (un)subscribe, where messages are archived, etc:
http://www.techfak.uni-bielefeld.de/bcd/Perl/Bio/vsns-bcd-perl.html
====================================================================