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


From: Padmakar Vishnubhatt <padmakar@Eng.Sun.COM>
Date: Wed, 09 Jul 1997 08:01:28 -0700
Message-ID: <33C3A7C8.6B0@eng.sun.com>
To: www-jigsaw@w3.org
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. 

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. 

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

(*)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. 

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? 

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 

        at w3c.tools.dbm.jdbm.restoreHeader(jdbm.java:390)
        at w3c.tools.dbm.jdbm.<init>(jdbm.java:841)
        at w3c.tools.store.StoreEntry.getStore(StoreEntry.java:91)
        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.

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.
(*)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 

Padmakar (Paddy) Vishnubhatt

Note: (*): Questions
Received on Wednesday, 9 July 1997 11:01:39 UTC

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