-----Original Message-----
From: Chris Winters [mailto:[EMAIL PROTECTED]]
Sent: 08 December 2000 14:43
To: jBoss
Subject: Re: [jBoss-User] CMP
<snippedy, snip>
<CW says:>
However, if you're doing multiple things with these
objects -- harvesting demographic information, tracking
customer service requests, whatever -- then I think it makes
sense to keep the objects as granular as possible and glue
them together with behaviors from stateless session beans.
</CW says:>
That's fine imo, just don't make all those tiddler entities EJB entity
beans. You could just use JDBC.
<CW says:>
Yes, this means there will be more objects "floating around"
in the container, but that's the container's problem. I
don't mean to be flip about this, it's just that I don't
want to spend a lot of time modelling my data in a
particular (and IMO unnatural) way because the container
can't handle it quite yet.
</CW says:>
Ah, no. I think you're missing part of my point. In the respect you describe
EJB works exactly as it should. It's a component model. Big chunky things.
We've christened ours "Broad Beans" (our Session Beans are "Runner Beans"
;). Our Broad Beans contain (typically) 5-10 separate entity classes - we
haven't merged the classes together or anything horrid like that, we've
simply packaged them in a sensible way in order to reduce expensive comms
and server management.
<CW says:>
Perhaps that's just my faith in
Open Source -- if it's a problem for me, then it's also a
problem for the authors, who are much smarter than I am and
will figure out a way around it. Marc's recent e-mail about
how JBoss manages all these objects rewards my faith :-)
(And so does my experience with countless other OS
projects.)
</CW says:>
I would be extremely surprised if it changed. Managing stateful, and in
particular persistent objects, in a potentially massively multi-user
concurrent system is always going to be extremely expensive in terms of cpu
and memory and other resources (and that's ignoring issues of failover and
so-on).
> The final, not problem, but limitation of CMP is that you
should definay
> *not* access the underlying database from outside of
EJB-land, and you can't
> integrate with legacy databases.
<CW says:>
I got this impression too. This rubs me the wrong way a
little -- probably since Perl is so good at glueing
heterogenous systems together -- but's it's not
insurmountable. Just some more thoughtful design work.
</CW says:>
LOL - Comparing Perl to EJB is like comparing MS-Access to Perl <snicker>.
They're chalk and cheese. Java in general has been extremely well designed.
EJB still has some rough edges and holes (I suspect the designers were
pushed to get something out quick to counter MTS and to make Java and
Enterprise development language - but that's just supposition) but overall
its reasonably well designed.
Anyway, use BMP, or skip EJB entities altogether and use JDBC (you get many
of the benefits anyway because the Container intervenes).
Just because CMP doesn't do everything automagically doesn't mean it should
;-) Treat it as a *simple* automatic persistence mechanism, with all the
trade-offs that implies, and you won't go far wrong. But there may be more
appropriate mechanisms eg BMP and not using EJB entities at all.
<CW says:>
I hope other folks can chime in about CMP. I'm still
learning and would love to hear about experiences elsewhere
and in the real world.
</CW says:>
CMP is good for: Learning EJBs (its one less thing to worry about to start
with) and for simple, low volume systems. This will change somewhat in
EJB2.0. But regardless - EJB entities should be big chunky things, not tiny
little basic entities.
</snippety, snip>
Edward
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
