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

Re: The lightbulb just isn't going on....

On Tue, 09 May 2000, Brian Weaver wrote:
> Hi All,
> 
> 	I'm in the middle of looking/updating the OPP code to support the standard
> javac options. This is a nice break from the rather mind numbing experience
> myself and a fellow developer are trying to figure out.
> 
> 	As part of the OpenNMS bluebird project I've be doing a proof of concept
> w/ozone to implement an SNMP configuration database. We have all the
> realavant information in an XML file, but I would perfer not to have every
> process using the java SNMP libraries to preprocess that file. So I was
> going to have a single process to read, process, and load converted objects
> into the ozone db. This serves the purpose of learning how ozone works,
> seeing how it performs under minimal loads, and centralizing the data.
> 
> 	To this end I created three interfaces and the related implementation
> classes. There is the core information about all configured nodes
> (SnmpConfigData.java & SnmpConfigDataImpl.java). The other two classes
> inheriet from the core class and extend it by adding IP address(es) to
> provide matching. Creating, retreving, and deleting the three classes to the
> database should be fairly straight forward.
> 
> 	Ultimately, what we're trying to accomplish is to have an "lookup" object
> that store one default configuration, a list of specific info by ip address,
> and a list of specific info by a range of ip addresses. I would like for the
> lookup object to have methods for creating new configuration objects, from
> passed information, in the server and the keep a reference to the real
> object. Likewise, when a client lookups an ip address I would like to have
> the lookup object pass a proxy object of the correct type back to the
> client.
> 
> 	There is an article in the ozone-db mailing list archive about peformance
> (http://www.ozone.org/ozone-list/01-2000/msg00483.html) that discusses
> issues related to creating objects in the client vs. the server. I have been
> unable to find the associated '_populate' method code reference in the
> reply. Are there any examples of creating objects in the server? The default
> documented tutorial doesn't explain how to create database objects from an
> object that's in the server.
> 
> 	If this is confusing, we'll it's because I'm confused too. I feel like I'm
> missing something (I feel kinda light headed, so perhaps it's a brain) and
> the lightbulb still isn't comming on. As Curly would say "I keep trying to
> think, but nothin' happens."

Okay, then here goes our Tuesday-afternoon-quick-and-dirty-tutorial ;)

When programming an ozone app you need to distinguish between your normal
classes and database classes. The ordinary ozone API
(org.ozoneDB.OzoneInterface) is used to handle database classes and
objects. So instead of creating an object via new <classname> - createObject()
is called. In the client probably a RemoteDatabase object represents the
database. Because of the single-instance architecture of ozone this *always*
creates an object inside the server.

In most cases a transaction creates more than one object. For example the
populate method creates a number of Car objects and adds them to a Garage
object. So the database object *itself* needs to access the ozone API methods.
Therefore each database class implements the OzoneCompatible interface which
provides the database() which returns an implementation of OzoneInterface which
can be used from inside the database object. This class is simply called
Database. An object of type Database represents the database in a database
object just like RemoteDatabase represents the Database in the client. (in
other words: each database object has an associated OzoneInterface that
provides the ozone API/environment for it) So in fact, the code that
populates the Garage with cars can run on the server or in the client. If it
runs on the client, you need explicite transaction demarcation. And, each
createObject() call and all method invocations are need to be send to the
server over a socket connection which is very slow. The proper way is to put the
populate code in the Garage class which is a database class itself. Then you
don't need explicite transaction *and* the code is much faster because in runs
inside the server -- That's the difference ;)

Hope this helps.


Falko
-- 
______________________________________________________________________
Falko Braeutigam                         mailto:falko@softwarebuero.de
softwarebuero m&b (SMB)                    http://www.softwarebuero.de