W3C home > Mailing lists > Public > www-jigsaw@w3.org > July to August 1997


From: Anselm Baird_Smith <Anselm.Baird_Smith@sophia.inria.fr>
Date: Thu, 17 Jul 1997 17:29:51 +0200 (MET DST)
Message-Id: <199707171529.RAA23911@www43.inria.fr>
To: Padmakar Vishnubhatt <padmakar@Eng.Sun.COM>
Cc: www-jigsaw@w3.org
Padmakar Vishnubhatt writes:
 > I have a question w.r.t the design philosophy of using jigsaw as an oodb
 > server. Our objective is to do exactly that - treat a webserver as an
 > object server. Although persistence is one of the strengths of jigsaw, I
 > did not see any other solution (that has been implemented) apart from
 > SimpleResourceStore as the persistence mechanism, which is very limited
 > in its capicity to scale to handle larger and more numerous objects. 

jdbmResourceStore is another (more scaleable one), but I agree that in
general, Jigsaw should be used in conjunction with a real-strength
object oriented database.

 > The question is to replace SimpleResourceStore with a more advanced
 > database management system - say another oodb or jdbm (at least). As I
 > saw in your archive, this topic was already visited and I did not see
 > any straightforward solution yet - although it was mentioned that a
 > "std" configuration file will be used to determine the exact
 > implementation class of ResourceStore. 

The proxy cache uses the jdbmResourceStore to keep track of cached
entries; you may want to have a look at
w3c.www.protocol.http.cache.CacheFilter to see it at work.

As you mention below (I think), there is a problem in the
ResourceStoreManager, that will only create SimpleResourceStore even
though the file was originally intended to be managed by a
jdbmResourceSTore. The problem is pretty simple: I was planing to put
within all store headers the name of the class that knows how to
manage it (SimpleResourceStore does this already). However
jdbmResourceStore manages the file header by itself and interacting
with it would introduce some bad dependencies.

In another life, I would probably have one set of properties per store
(well, at least of some sort) and use that to get that infos.

 > In order to circumvent this problem, for the time being, I hacked your
 > getStore method in StoreEntry to read system properties where it will
 > read the implementation class of the ResourceStore. I have a class
 > called DBStore which represents a singleton ResourceStore object (this
 > also I think was one of the questions in the same thread). So that
 > getStore always returns the same instance instead of creating new
 > instance for each directory (which I understand is not entirely
 > neccessary -right?). In this class (DBStore), I read another System
 > property which tells me what kind of database management system that I'd
 > like to use - it could be OPJResourceStore, PSEResourceStore,
 > jdbmResourceStore, SybaseResourceStore, mSQLResourceStore, or
 > JDBCRsourceStore. 
 > (*)Could you please comment on this approach whenever you get a chance?
 > The basic idea behind this is to really see jigsaw as a oodb server -
 > the resources (data) can be made persistent anywhere and the server gets
 > the resources in an orthogonal manner. 

This is one of the design goals of 2.0: basically take any data source
(odbc, jdbc ascii file, etc) and make the server see them as
resources. Part of that is implemented and may be included in next
release for interested readers only; 

 > In this regard, I tested out the use of jdbmResourceStore to make
 > everything (cache + server-relevant resources) persistent. In order to
 > do so, I am stuck with the pickle/unpickle methods within jigsaw for
 > bootstrapping purpose. What I was hoping for was as follows:
 >  - I pass jdbmResourceStore as the implementation class for
 > ResourceStore using System property. 
 >  - Then, in getStore of ResourceManager (actually StoreEntry), I
 > instantiate a singleton object of jdbmResourceStore.
 >  - Then I assumed the following w.r.t. jdbmResourceStore.java code, the
 > initialize method calls a constructor of jdbm class sending a file
 > object as a parameter. What I assumed was that jdbm will read this file,
 > unpickle the data in it and create a jdbm object (with the resource
 > stored in it) for use whenever its read next time thus using the file
 > object for bootstrapping purposes. (*)Is this correct? 
I think so (I mean if I have understood correctly)

 > Well, I tried running the server using jdbmResourceStore as the
 > implementation class; I could not convert the file to jdbm store because
 > of an outofmemory error 
 > java.lang.OutOfMemoryError
 >         at w3c.tools.dbm.jdbm.restoreHeader(jdbm.java:390)
 >         at w3c.tools.dbm.jdbm.<init>(jdbm.java:841)
 >         at
 > w3c.tools.store.jdbmResourceStore.initialize(jdbmResourceStore.java:604)
 >         at w3c.tools.store.StoreEntry.getStore(StoreEntry.java:91)
 >         at
 > w3c.tools.store.ResourceStoreManager.loadResourceStore(ResourceStoreManager.java:219)
 >         at w3c.jigsaw.http.httpd.initializeRootResource(httpd.java:611)
 >         at w3c.jigsaw.http.httpd.initialize(httpd.java:1442)
 >         at w3c.jigsaw.http.httpd.main(httpd.java:1670)
 > (*)Can you please help me out of this error? Thanks.

You probably did weird things to the store...I guess I understand that
you did pickle a few objects to som efile, and you're trying to access
that file through jdbm afterward ? You should rather create a jdbm
object first (pass it an empty file).
Add some objects into it (identifier is the key, the value is the
pickled resource), then you'll be able to bootstrap the whole thing.

 > I understand that some people have already managed to use rdbms to make
 > some server resources persistent - but they stored pickled data in the
 > store which requires to translated each time the object is accessed - I
 > understand there is caching, but this is another layer that can be
 > avoided when one uses a full-fledged oodbms such pse, poet, etc.

Correct and again, being able to use existing oodbms as resource store
is a design goal for 2.0

 > (*)Could you suggest a design that will fit this piece (persistence)
 > into jigsaw (an example implementation of ResourceStore would be answer
 > from "heaven" and would tell us what you have in mind when ResourceStore
 > is implemented). Database caching is taken care of by the oodbms vendors
 > so that effort can be saved when it comes to writing this
 > implementation. Please 

Unfortunatelly the 1.0 design doesn't allow much cooperation wit
hexisting dbms. The problem is in the way resources are accessed. The
2.0 design has a notion of ResourceReference which allows you to map
resource accesses to oodbms transaction (when desired)

Received on Thursday, 17 July 1997 11:30:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:31 UTC