----- Original Message -----
From: "Kenworthy, Edward" <[EMAIL PROTECTED]>
To: "'jBoss'" <[EMAIL PROTECTED]>
Sent: Friday, December 08, 2000 10:37 AM
Subject: RE: [jBoss-User] CMP
> That's fine imo, just don't make all those tiddler entities EJB
entity
> beans. You could just use JDBC.
Sure, but then that defeats the whole purpose of using a data
abstraction layer :-)
Have you (or anyone) tried using something like Castor or other
JDO implementation within jBoss or any other container?
> 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.
Well, like I said, I'm just learning. :-)
This method you describe of doing things makes some sense. I just
need to get my hands dirty with something like it. Plus the
mapping of table -> entity bean makes some easy sense and is
pretty simple. Good place to start.
> 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).
This also is true.
> 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.
Sorry, I didn't explain myself. The database package for Perl
(DBI) is much more 'bare metal' than anything I've seen with Java
so far, including JDBC. (As a result it's quite fast, but that's
getting into all those efficiency issues.) T
his is why looking at the database activity from CMP shocked me
so much -- it just appears so wasteful to have so much going on
to do relatively trivial operations. (Doing an update everytime
you call a 'set' method of an entity bean seems nutty.) That's
not to say I can't see *why* this is done, just that it was
surprising.
> 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.
I agree. It takes a general approach I agree with -- get things
done right in the beginning and then worry about making them
efficient.
> Anyway, use BMP, or skip EJB entities altogether and use JDBC
(you get many
> of the benefits anyway because the Container intervenes).
This is the conclusion I'm coming to, although I'd rather have
something a little higher level than JDBC and a little lower
level than BMP/CMP. (Again, this is coming from my Perl
background where I wrote a fairly extensive object persistence
scheme...)
> 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.
I think stressing the *simple* part is important -- the
literature doesn't seem to do this as much when discussing CMP.
Thanks for the discussion. It's quite informative!
Chris
--
Chris Winters <[EMAIL PROTECTED]>
Internet Developer
http://www.optiron.com/
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
