Krishnan Subramanian wrote:

> So, after all this ranting, is this what PbR implies?:

>  - Now patterns and strategies will start appearing that take advantage
>    of PbR semantics. This would be good thing if you took it with
>    a pinch of salt. However, I fear PbR might be overused/overrated i.e.
>    developers might be misled into using PbR when there is no need for PbR
>    in the first place. A typical case of "Hey ... this feature is cool and
>    everyone's talking about it - let's use it (regardless of whether it
>    provides any additional value/benefit)".

The biggest place where we find this to be of benefit is with a case you
haven't mentioned - arrays of stuff. For example, internally the beans
use a long that is used as a primary key for SQL and also EJBs. When we
ask for data, instead of asking for an array of primary key objects, we
just deal directly with the lowest level information. Less object
creation, less garbage, and much more direct sets of information,
including self modification if needed (we have no use for this yet). For
example, asking for a sorted array of items returns a 10K array of longs
rather than 10K objects. These objects, being primary key classes may or
may not be immutable (automated testing to know this can be easily
tricked into giving the wrong answer) so even for local methods you
can't do anything for optimisation.

At least in our application where there are many to many relationships
between most of the data structures, we strictly avoid CMP/CMR as the
load of one bean could quite easily trigger the load of the entire
database. Obviously this is undesirable. To avoid this issue, we end up
returning the IDs and force the client application to do a separate call
to fetch the related objects. With some good client side caching, this
can then be minimised to almost no traffic at all.

So to us, PbR is basically a way of doing stuff faster rather than using
the actual reference stuff. And also for us, the references are mostly
mutable so all the optimisations you nominate are not valid for this
application.    We also design with PBR in mind, for example we don't
trash the passed arrays and the method signatures are different for
remote v local.

--
Justin Couch                         http://www.vlc.com.au/~justin/
Freelance Java Consultant                  http://www.yumetech.com/
Author, Java 3D FAQ Maintainer                  http://www.j3d.org/
-------------------------------------------------------------------
"Humanism is dead. Animals think, feel; so do machines now.
Neither man nor woman is the measure of all things. Every organism
processes data according to its domain, its environment; you, with
all your brains, would be useless in a mouse's universe..."
                                              - Greg Bear, Slant
-------------------------------------------------------------------

===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST".  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".

Reply via email to