Here is some more information about EJBs and threading.
Reentrancy is when a single thread "reenters" an object which it is
currently using higher up in the call stack. For example, thread 1 executes
a method in bean A, which makes a call to a method in bean B which in turn
calls a third method in bean A again. The thread is said to have
"reentered" the bean. Reentrancy says nothing about whether a different
thread can access the bean instance or not. According to Sun's web site,
only entity beans can be flagged as reentrant.
As I mentioned earlier I don't know all of the details about how app servers
deal with concurrent requests to EJBs. I went and did some research to see
if I could come up with a more definative answer.
Sun's site is woefully lacking in information on the subject, except to say
that the application server handles the threading issue. I have looked on
several other web sites without luck. I finally went to my copy of
"Mastering Enterprise JavaBeans" by Ed Roman. He makes several comments on
the subject which I have included below.
To make a long story short, I think that people on both sides of the
argument can say that they are correct. He says that EJBs are single
threaded objects. A given EJB instance can only be accessed by one thread
at a time. The app server, however, is responsible for creating and
managing pools of EJB instances so that it can route concurrent requests to
different instances. This gives the appearance and scalability of
multithreading.
In other words, it is correct to say that EJBs are single threaded objects
but it is not correct to say that a given EJB class can only be accessed by
one client at a time.
The hope of the creators of the spec was to create an environment where the
benefits of multi-threaded server objects would be realized without
requiring the component developers to understand and handle threading
issues.
See the excerpts below if you want more detail. If you want a free
electronic version of this book, go to
http://www.theserverside.com/resources/book.jsp . You will have to sign up
but the registration is free and there are other benefits on the site that
make it worthwhile.
Page 32
"EJB also offers "plug-and-play" enterprise features. With EJB, you barely
need to know anything at all about middleware to construct components
designed to run in a scalable, multi-tier architecture. Rather than writing
to middleware APIs (which is the old CORBA style of distributed object
computing), your components gain middleware services implicitly and
transparently from the EJB server, without writing one line of middleware
code yourself. The application server implicitly handles transactions,
persistence, security, state management, component lifecycle, threading, and
more."
Page 48
"Implicit multiclient support. EBJ servers automatically route concurrent
requests from clients. EJB servers provide built-in thread support,
instantiating multiple copies of your component as necessary and channeling
client requests to those instances."
Page 60
"One great benefit of EJB is you don't need to write thread-safe code. You
design your enterprise beans as single-threaded components, and you never
need to worry about thread synchronization when concurrent clients access
your component. Your EJB container will automatically instantiate multiple
instances of your component to service concurrent client requests."
-----Original Message-----
From: Mark A. Sandee [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 07, 2001 1:18 PM
To: JRun-Talk
Subject: RE: beans vs ejb's (was "RE: Ist it possible to seperate EJB
and Servlet Server?")
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
