Hello,
I have two questions:
1. Is automatic "lazy-loading" implemented in JBoss? I had to write it myself in
my EJB...Can you
give an example?
2. Why should a BMP be better than a CMP in terms of performance? Is the
generated
data access code that poor in CMP?
Rickard Oberg a �crit :
> Hey
>
> > In jBoss, can EJB objects be read by many users at the same time?
>
> EJBObjects (== the client proxy+container invoker in our case) supports
> several users invoking them at the same time. I.e. you can have several
> client threads working on the same EJBObject if you want.
>
> > Weblogic
> > grabs (or used to grab) a pessimistic lock on entity beans during a simple
> > read operation. This was so odious that we got rid of all our entity
> beans.
>
> Note that this has nothing to do with the above. Now you are talking about
> the entity cache concurrency scheme. Yes, we use a pessimistic locking
> scheme just as Weblogic does. I would recommend that you use the "supports"
> tx mode for read methods to minimize the locking time. Are you doing that?
>
> We do have plans to add an alternative cache in the next version that uses
> optimistic locking, i.e. maintains one copy/tx so that several threads can
> use the same instance at the same time.
>
> We alse have a "read only" flag that should allow several threads to use the
> same instances at the same time without locking each other out. Not sure if
> that was fully implemented though (will check).
>
> > I was just yesterday (Sunday) at the "EJB/J2EE for large scale
> development"
> > tutorial at OOPSLA that was given by Peter Herzum. He recommends *never*
> > using CMP that maps one bean to one table if you need your application to
> > scale (both for runtime and development), but instead have one bean map to
> a
> > minimum of 4-5 tables (10 is more common in his experience) that fit into
> a
> > logical grouping. The bean can be either a Session Bean or BMP (bean
> > managed persistence) Entity Bean. (I know this sounds harsh, but the more
> I
> > thought about it, the more I realized that it makes a lot of sense--and it
> > fits with our experience).
>
> What was the rationale? (I heard Peters presentation a couple of weeks ago,
> but many of his points are based on how "heavy" EJB implementations work.
> The more lightweight jBoss approach invalidates many of the concerns.)
>
> Of course, EJB 2.0 CMP invalidates pretty much all of that FUD. I don't
> think it would be possible to make something handcoded (either BMP or
> session/JDBC based) more efficient than EJB 2.0 CMP.
>
> > Another statement from Peter's presentation was that "Only the business
> > objects that need to be accessed directly by the client need to be
> > enterprise beans: Use helper objects". Accessing Entity beans from
> Session
> > beans creates the risk that a rogue programmer will access those entity
> > beans directly from the client instead of going through the session bean.
> > Granted, security can control this, but that's not really what security
> > should be used for.
>
> It also depends on whether the beans are exposed. Currently all beans are
> bound into JNDI, but IMHO that should not be the case. It should be possible
> to have some beans not exposed at all, but only available internally for
> other beans to use.
>
> > Basically, we lost nothing (security, transactions, etc) when we flattened
> > out our EJB layers from three to one. What we gained was simpler, easier
> to
> > maintain code, and a tremendous improvement in performance.
>
> I don't agree. You can get better performance with CMP (depending on your
> particular usecases of course), you don't have to write SQL (huge win in
> terms of bug-iness), and you get automatic lazy-loading. Hm.... I have seen
> this discussion a lot of times, and sometimes it is valid, but more than
> often it is just based on bad EJB/CMP implementations and nothing inherently
> wrong with EJB/CMP.
>
> /Rickard
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
