Re: design, RMI
Ken Brewer <kbrewer <at> microremedies.com>
2003-01-26 17:04:31 GMT
Thanks for your response. I understand some of your points but other are
confusing. My requirements of the DB are minimal but I'm still not sure
that ozone will fit the bill. It seems that the guidance I'm getting is
very contradictory and there are several design gotcha's with ozone.
Use the ValueObject pattern but mere Serializable objects could be
problematic. That means all data access would have to copy values back
and forth between OzoneObjects and ValueObjects which causes more coding
and reduces performance.
Collections should contain proxies in order avoid loading each and every
entire object of a collection. My question then is: will using proxies
inside the db result in the same RMI, or similar, overhead as if the
proxy was used outside the db? The answer to this question was: do
prototyping. That makes no sense.
The documentation says that every proxy method call is itself a
transaction. Well, if so, then every get/set operation of a proxy is a
transaction? That is absurd, transaction overhead where I don't need it.
So then, to control a transaction, I have to pass ValueObjects to a
proxy method call then copy data back and forth between the
ValueObject's and the OzoneObject's because mere Serializable objects,
ValueObject's, cannot be persisted reliably.
If ozone and the app are running in the same VM, you still need to use
proxies to control transactions and get lazy loading but will I be
getting RMI too when I don't need it?
Then there's the searching issues. I asked for help on creating indexes
on fields and unique fields. The response was essentially that I was
thinking RDBMS not OODBMS. Ozone has no publicly documented way of
finding an object or determining what object types are stored in it or
anything of the sort. That leaves the programmer to code in mechanics of
I'm not knocking ozone. I would love to be able to use a pure java
OODBMS and I'm depressed at the thought of doing another OR mapped
application but your advice isn't very helpful and doesn't seem to
consider the requirements of a real world application.
On Sat, 2003-01-25 at 09:34, Leo Mekenkamp wrote:
> On Fri, 2003-01-24 at 15:27, Ken Brewer wrote:
> > Another question along the same lines. Consider an OzoneObject having a
> > Hashtable containing objects which is being accessed by code running
> > inside an OzoneObject, inside the DB that is. I'm trying to understand
> > how I would ensure that the Hashtable elements were lazily loaded
> > instead of all being loaded into memory with the Hashtable? As far as I
> > understand, the solution is to make the Hastable elements Ozone Proxies?
> Yes and no. All objects in a hashtable are all (de)serialized together
> with that hashtable. References to an ozone object are (should always
> be) proxies. So when you store an ozone object in a collection, you
> store a proxy to that ozone object. All those proxies are the actual
> objects in the hashtable.
> That is also the reason why you should be _very_ careful with the use of
> 'this'; in 99.9% of all cases where one uses 'this' in a 'normal' java
> program one must use 'self()' in ozone objects.
> > So then, the proxies provide two valuable features, lazy loading inside
> > the db, and communication to a standalone server? My concern is that
> > using proxies inside the db to gain lazy loading will cause additional
> > unnecessary overhead like RMI.
> That's what prototyping is for
> > On Fri, 2003-01-24 at 13:51, Ken Brewer wrote:
> > > I'm looking for more opinions, experiences, etc. on an idea.
> > >
> > > I've currently designed all of my persistent objects as unnamed
> > > OzoneObject's. I've created a home class for each object type with a
> > > Hashtable containing Proxies to each instance of each class. This works
> > > but I'm considering changing the data objects to be simply Serializable
> > > and stored within the hashtable home for each type. This is so that the
> Could work. But you would have to keep in mind that an OzoneObject can
> be referenced from another object; a mere Serializable cannot. Well, it
> can actually, but when ozone persist 2 different ozone objects
> referencing the same Serializable, then you might end up having one OR
> two serialized versions of that Serializable; the serialization api
> stores a Serializable only once within an object stream, but 2 ozone
> objects might be saved in different object streams.
> If you use Serializable objects to store in your collection, make sure
> they are only referenced by exactely 1 ozone object; also all changing
> of that Serializable must take place through its contaning ozone object.
> So it can be done, but you are walking a very thin line.
> > > client can manipulate the objects and have control over when and what is
> > > communicated via RMI rather than having every get/set immediately
> > > persist to ozone. I will add,delete,update methods to the OzoneObject
> > > home classes which will be called when the client is ready to persist
> > > something passing the proper Serializable object.
> Sounds like a ValueObject design pattern; easy to implement because
> ozone already uses an interface structure.
> I understand that
> > > storing Serializable objects in an collection in ozone will cause all
> > > collection elements to be loaded into memory. Obviously, I want to avoid
> > > this. I was thinking of creating a wrapper OzoneObject for each
> > > Serializable object to avoid that. Would this work as expected?
> Yes, probably. But I would not like to be the one doing maintenance on
> that sort of code
> Leo Mekenkamp | Tired of Windows' blue screens, Internet Eplorer
> +31 (0)6 41234919 | Outlook security vulnerabilities and Office'
> ___________________| Why not try the free and open source alternatives:
> http://www.linux.org, http://www.mozilla.org and
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> Ozone-users mailing list
> Ozone-users <at> lists.sourceforge.net
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!