RE: Additional interfaces for proxy objects?

You've got several options.  It seems the simplest to implement from
where you are now (though perhaps suboptimal) would be to just use the
factories to create all your lines as database objects.  For transient
Lines, don't worry about them - just let the garbage collector clean
them up.  This should work, but you may want better performance.

I have some experience working with graphics, so let me offer you some
design advice. In graphics, you typically have large numbers of very
small objects (points, lines, etc.), and a performance critical
environment.  Keep this in mind.  You might see better performance by
making your graphic primitive objects serializeable, but not ozone
objects.  Use ozone objects to collect and store them persistently (such
as a display list). This way you create Line outside the database, then
store it in something like an ozone collection object. Focus your design
effort on intelligent ozone collections that give you the exact data you
need (e.g. the lines within a specific bounding box). 

Remember, each call to an ozone proxy object method is essentially a
remote method invokationl.  If you have hundreds or thousands of lines,
all that network chatter is going to slow down your application.  Better
to make a small number of remote calls then, operate on 'local' Lines.

~Jimmy


On Wed, 2004-12-01 at 05:04, Aidan Slingsby wrote:
> > Is it possible for proxy classes to implement more than one 
> > interface?  I was hoping that OPP would would automatically 
> > give the proxy classes all the interfaces listed in the Impl 
> > class, but they are only given the one Ozone interface 
> > (inherited from OzoneRemote).
> 
> I should perhaps give a few more details of what I want.  I am slightly hazy
> about exactly how all this works - sorry.
> 
> I used to have an interface called Line (which extended OzoneRemote) and a
> class called LineImpl (extended from OzoneObject).  Proxy classes were
> generated in the usual way.
> 
> The problem is that there are cases when I wish to temporarily create a
> LineImpl) i.e. outside the database to be used in the short term.  I'd do
> this by new NodeImpl().  As long as I wasn't passing between client and
> server, this was fine.  And I didn't, because it was only short-lived.  This
> was my workaround.
> 
> There is now a situation where I wish to pass the temporary Line between
> client and server, and of course I get a "not (yet) in database" error.
> 
> My solution was to have two interfaces.  One called Line (standard Java) and
> one called LineDB (which extends OzoneRemote), both with the same methods
> defined.  Then have a class LineGeometry (a standard Serialisable Java
> object) and LineDBImpl (an object object).  LineDBImpl is a wrapper object,
> which has a protected LineGeometry variable and all the methods in the
> interface passed through to LineGeometry.  Since LineGeometry implements
> Line and LineDBImpl implements Line and LineDB, they can both be treated as
> Line.  The idea is that a Line could be a LineGeometry, a LineDBImpl (which
> wraps around LineGeometry) or a proxy.  I was hoping that the proxy object
> could also implement Line and LineDB, so it can be treated as Line.
> 
> Problem is it seems that it can't. 
> 
> So my question is: is there a way to implement what I want?  I.e. to have an
> interface "Line" which is implemented by an Ozone class, a Ozone proxy class
> and a conventional Java class, in which the former 2 works with the database
> as they are supposed to and in which the latter is erialised across instead
> as it's supposed to?
> 
> I hope it's reasonable clear.  Thanks for any help you may be able to give.
> 
> Aidan.
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now. 
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Ozone-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/ozone-users



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/