I agree with the discusssion below, but add:
EJBs default to being single threaded but this behavior can be modified:
See the EjbProperty "IS_REENTRANT".
Direct from JRun's API documentation --
"The name of the property for specifying if an entity bean is reentrant. The
container allows reentrant calls if set to true. If set to false, the
container prohibits reentrant behavior. If not specified, the property
defaults to false.
Example: ejb.isReentrant=true
The value of this constant is "ejb.isReentrant".
By the way,
We're using lots of EJB's and I think they're great. We ripped out a ton of
home-grown caching code and connection pooling code and now our product is
much simpler, more stable, and runs faster.
Its performance was really poor until I ran a profiler and discovered we
were obtaining the context over and over again. Also, we had a lot of
trouble getting complex queries (with joins and/or nested queries) working
in CMP EJBs. I did move these to Session beans (although a BMP bean could
have been used). We're still using JRun 3.0 SP2 -- I've read on
Macromedia's web site that CMPs support complex queries -- have to give it
another try with next round of funding.
I also had a bit of trouble writing to BLOB and CLOB fields in Oracle 8.1.5
and 8.1.7. I couldn't get this to work with a pooled connection since it
required turning Autocommit off to do the required SELECT.. FOR UPDATE.
Once these bottlenecks and oddities were overcome, I find EJBs to result in
a very maintainable, clean system that by default is "safe" as opposed to
servlets, for example, where the default is multi-threaded. How many
servlets are out there that have accidents waiting to happen programmed into
them? Certainly they can be programmed safely, but programming them safely
is a heck of a lot more complicated than using EJBs.
Where the EJB caching or autocommiting is a problem, turn it off and role
your own. Otherwise, don't throw out its great features everywhere because
of few localized problems that need special treatment.
Mark S.
-----Original Message-----
From: Scott Stirling [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 06, 2001 2:53 PM
To: JRun-Talk
Subject: RE: beans vs ejb's (was "RE: Ist it possible to seperate EJB
and Servlet Server?")
> From: Haseltine, Celeste [mailto:[EMAIL PROTECTED]]
{snip]
> Also, to my knowledge, EJB's are a single threaded model,
> i.e.. they do not support multi-threading. Or did I miss
> something in my reading of EJB's?
1. The EJB spec says EJBs cannot create threads. Most app servers don't
actually enforce this restriction (or others, like the ability to read or
write a file, or the ability to open a socket), but you can enforce it via
programming practice or Java security policies.
2. EJBs themselves are generally implemented by the container as
single-thread model, but the container creates lots of them, so the
single-threadedness is transparent to the client. The EJB server has leeway
to implement the EJBs in a variety of ways (not sure how many ways are
really viable for performance or J2EE-compatibility issues), but the
container has to ensure that EJBs are thread-safe and that the container can
handle multiple concurrent clients. So, in short, EJBs may not be
multi-threaded internally, but the containers maintain the apparent behavior
that they are.
Scott Stirling
JRun QA
Macromedia
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
