[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: OO DB design w.r.t. performance issues

On Wed, 17 Jan 2001, Peter Schuller wrote:
> Hello,
> 
> I've been thinking long and hard about how to design an OO DB such that it
> ends up being scale:able. While it would be nice to be able to reat the
> database objects just like any other objects when using them, it would
> require manual transaction handling, and it would slow things down
> considerably because of the large amount of remote method invokations.
> 
> In this case, I am working on a web-based system. The problem lies in
> assembling the pages sent to the client. For example, in a list of 50 items
> I don't want to make 50 remote calls do the DB. (It's an "organizer" typ web
> app; folders, todo items, etc).
> 
> The two best options I've thought of are:
> 
> (1) Provide a generic interface for running Runnable objects inside the
> database. This is fine in an environment (such as mine) where clients are
> fully trusted. However, it ads a certain amount of overhead because more
> paramters (in particular, the Runnable implementor) needs to be passed (and
> hence serialized/de-serialized).
> 
> (2) Create some kind of "utility" class (known by the server) and insert an
> instance of this class into the DB; with relevant references to other DB
> objects. I would then create some kind of container objects for specific
> purposes. Eg, I could have a method "public FolderView getFolderView(String
> folderid, User user)" that interacts with DB objects inside the server and
> returns a pure non-DB object container with the information relevant for
> producing a folder view (list of sub folders, todos, or whichever items are
> relevant).
> 
> While the second choice looses some of it's "elegance" in that application
> logic is being performed inside the DB (in a non-dynamic way), I'm leaning
> towards it.
> 
> What do people usually do in these cases? I'm not really happy with any of
> them because both partly undermines the elegance of using an ODBMS in the
> first place. But I see no other alternative.

I'm not sure if I got you right here. It sounds like you are looking for a way
to execute methods inside the database server (to avoid to many remote calls).
Well, this was the very first thing that the very first ozone version was able
to do. The business logic of your app can and should run inside the server - as
methods of database objects.

In your special case you cannot execute all the logic inside the ozone server
because it isn't possible to run a web (servlet or JSP) environment inside the
ozone server. IMO your options are:

- try to reduce remote calls as much as possible and rely on the performance of
ozone for the rest ;) 1 - 2ms per call is not _that_ much

- make a container that aggregates the result values of several calls that are
normally not a method; is not that ellegant but we discussed this approach some
time ago and for trees it seems a very good solution

- use XML to aggregate the return values; highly depends on your environment
but may be an option


Falko
-- 
______________________________________________________________________
Falko Braeutigam                              mailto:falko@smb-tec.com
SMB GmbH                                        http://www.smb-tec.com