|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?
guys, guys, the code is public and amounts to a wonderful
update fields with values where primary key is value
BMP will be better if you have complex queries that you have already
written. If not use CMP and jaws or cocobase for complex mappings.
generated SQL is quickly following the path of generated assembly code...
can you beat your compiler at optimized assembly code? ...
marc
|
|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]
|
|
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
