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]
