Ozone Users Guide

Although the situation has in recent years improved, these problems have merely been moved out of sight from the average developer. Technologies like Apache Torque and Suns EJBs are still hacks to get around some of the limitations of rdbms-es.

The iterator returned by Company.employeeIterator() of course returns an iterator that iterates over all the employees that that company employs. Now that we have these interfaces, we also need classes implementing them. That should not prove to be too much of a hassle. The only thing to keep in mind is that if you add a Person to a Company then that Company must also be automatically be added to that Person; it is a two way link. The easiest but not the fastest in execution time to do this is something like

        Collection employers = new TreeSet();
        public void addEmployer(Company employer) {
            employers.add(employer);
            // test to avoid endless recursion
            if (!company.hasEmployee(this)) {
                company.addEmployee(this)
            }
        }
	

Please note the /*update*/ comment at the end of the set*() methods. Unfortunately in Java there is no way to determine methods that change the state of an object. But Ozone has to know these methods because such methods are update transactions instead of read transactions. So the programmer has to mark update methods explicitely. There are different ways to do so:

Now we can compile the interface and the class. You can use the following command line:

In the last step we create the proxy class for CarImpl. Proxy objects are the substitutes for the database objects in your application. Their job is to pass your method calls for database objects through the connection to the database. They have the same interface as the actual database objects and you can work with them as they were database objects.

To create the proxy class for CarImpl we use the following command line: opp CarImpl

OPP is the Ozone Post Processor. It creates the proxy class for a given database class. In our example it creates a file named Car_Proxy.class.

Note that the Ozone server and the OPP have to have access to the class files of all Ozone related classes of an application. If you are working with packages, you must add the corresponding directories to you CLASSPATH. In this example we do not use packages. If there is the ./ directory in your CLASSPATH you can complete our car example by just starting the Ozone server and the OPP in the directory of this example.

At first the program connects to the database on host "localhost" at port 3333. If everything was okay, we get a Connected output. The next step is to reload our database classes with reloadClasses(). This is necessary if we made some changes in our class code and the Ozone server was not restarted. In this case it holds the old class bytecode in its cache and it would not use our changed version.

Because we used the create option the program creates now a new database object of the type CarImpl and gives it the name my_first_car.

Please note that this name has no conjunction with the _name -member or the name()-method of CarImpl. This a database feature and it helps us to get our car back if we restart our small program.

The next to method calls assign the name of our car with "gottfried" and the year of contruction with 1957. Last but not least we close the connection and our program has finished.

The following command line starts the application: ojvm MyApp print The application connects to the server again and get our car back by using the objectForName-method. Then it prints the name and the age of our car. If everything was okay we get the following output: The car gottfried is 40 years old. Finally we close the connection.

We can delete our car object from the database by calling: ojvm MyApp delete When you have enough played with your first Ozone-application you can shutdown the Ozone-server simply by pressing q (return) in the Ozone-server terminal window or choose the shutdown command from the administration tool.

In the next sections we will extend out example by adding a garage for out cars.

We will use a dictionary as the data structure for our garage. This dictionary contains all our cars identified by their name. The next step is clear: we have to write the implementation of our interface and we call this class GarageImpl.

        import org.ozoneDB.OzoneObject;
        import java.util.*;

        public class GarageImpl extends OzoneObject implements Garage {

            /**
            Set version of the serialized data to make it compatible with
            new class versions.
            */
            final static long serialVersionUID = 1L;

            private Hashtable	cars;

            public GarageImpl() {
                cars = new Hashtable();
            }

            public void addCar_update( String name, int yearOfConst ) throws Exception {
                Car car = (Car)database().createObject( CarImpl.class.getName() );
                car.setName( name );
                car.setYearOfConst( yearOfConst );
                cars.put( car.name(), car );
            }

            public Car carForName( String name ) {
                return (Car)cars.get( name );
            }

            public Car removeCar_update( String name ) {
                return (Car)cars.remove( name );
            }

            public Vector oldtimers() {
                Vector result = new Vector();
                for (Enumeration e=cars.elements(); e.hasMoreElements(); ) {
                    Car car = (Car)e.nextElement();
                    if (car.age() >= 20) {
                        result.add( car );
                    }
                }
                return result;
            }

            public void onDelete() throws Exception {
                for (Enumeration e=cars.elements(); e.hasMoreElements(); ) {
                    Car car = (Car)e.nextElement();
                    database().deleteObject( car );
                }
            }
        }
        

Most of the code above is selfexplaining. We add, get and remove cars identified by their name. It seems to be easy, but remember that the cars-list does not contain objects of the type CarImpl! It contains only proxy objects of the type Car_proxy. Each of these objects stands for a database object of the type CarImpl. Both of these types, CarImpl and Car_proxy, implements the Car-interface and the proxy object has the same behaviour as the corresponding database object. In Ozone you always work with proxy objects. The only exception of this rule is, you are standing in a method of a database object. In this case you have of course direct access to the object via the this-reference. Have a look at the oldtimers() method. The result bag the cars dictionary contain proxy objects and so the call to the age() method of the cars is an RMI call.

Finally we take a look at the onDelete-method. Every OzoneObject has this method and it is invoked when we delete this object from the database. This is similar to the destructor in C++. Our onDelete() should delete all the cars of the garage when we delete the garage itself. For this purpose we need a connection to the database so that we can call deleteObject(). The method database() gives us the right database proxy. Every OzoneObject has this database -method and with this link to the database you can call database methods like createObject() or deleteObject.

Now we have to compile the Garage interface and the GarageImpl class and we have to generate the proxy class. javac GarageImpl opp -p".*_update" GarageImpl Note the -p parameter. This specifies the pattern after which all update methods are named.

Have a look at the oldtimer section in the main() method: The result list of the oldtimer() method contains proxy objects. And so the calls of the age() and name() are RMI calls. But we call these methods from outside the server, this means the methods calls go through the socket connection. But the code looks straight forward. We have just written the code as expected - and it works. However, iterating over collections of database object outside a database method results in very poor performance and consistency problems. In fact all method calls from outside the Ozone server are transactions. If the method call returns, the transaction is commited, otherwise you get an exception and the transaction is aborted. You need not to explicitly start and commit transactions. This means all actions of a transaction must be grouped in one method. In our example we iterate over a collection of objects. Of course this should be a transaction because we do not want the GarageImpl object to be changed while we are working with it.