[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Ozone speed
On Wed, 13 Jun 2001, Eric Richardson wrote:
> Stan Pinte wrote:
> >
> > At 16:26 12/06/2001 +0200, Falko Braeutigam wrote:
> > >On Tue, 12 Jun 2001, Stan Pinte wrote:
> > > > hello,
> > > >
> > > > I have a small problem:
> > > >
> > > > I have a simple client-server program, which is doing 150 writes to the
> > > > database, and this takes more or less 12 seconds...I guess I have done
> > > > something wrong.
> > > >
> > > > Would someone point me to some good benchmarking code?
> > >
> > >See the samples in $OZONE_HOME/samples. You may start with simple and then
> > >check the OO1 benchmark sample.
> > >
> > >You probably did your 150 "writes" (calling update methods I guess) from the
> > >client code. Thus, each method call results in a roundtrip to the server and a
> > >complete transaction begin/prepare/commit cycle - which is probably not
> > >intended and slow. Putting the 150 item loop into a method of a database
> > >object
> > >is the solution. It's much faster _and_ encloses the entire work in _one_
> > >transaction.
> >
> > Well, my Postgresql relational engine handles 150 writes in a lot less than
> > 12 seconds...
>
> Since each write requires a transaction, this would be more like
> committing after every single transaction. This should slow things down
> a bit with a relational engine.
>
> In Ozone, can the client set the transaction boundary so each create or
> update is not in it's own transaction?
Yes, it can. This is needed for the BLOB and the XML subsystems. However...
> AFAIK they removed this in EJB
> and took the stance that clients should not deal with transactions which
> forces the developer to create Session beans to encapsulate and
> aggregate these types of actions.
... for 'ordinary' client development I perfectly agree with the opinion that
explicit transaction demarcation is not needed (and sometimes dangerous) on the
client side API. This is why we added this just when there was no chance to
avoid it.
Falko
--
______________________________________________________________________
Falko Braeutigam mailto:falko@smb-tec.com
SMB GmbH http://www.smb-tec.com