Please help me understand EJB

[HalcyonWild]

Hi,

I have read a lot about EJB. I have searched a lot on the Net for EJB
tutorials and EJB related guides and pages. Most of them begin at an
intermediate level. They talk about theory, without examples, even
trivial. Let us assume Stateless session beans for now.

This is what I have understood.
1. EJB are threadsafe components that run inside a container that
manages their lifecycle, their creation and destruction.
What does threadsafe mean here. I understand that for each request, a
separate EJB instance from the pool is assigned, which carries out
business logic.
Does it mean that two EJBs cannot modify the same record in a DB, at
same point of time. I dont think so they can, but I am not sure. Also,
will access to a common object(ie instance) be synchronized.
2. They say it does transaction management for you. What do we mean by
transaction management here. Transactions as in JDBC?. What if I am not
making any JDBC calls here. Is transaction management a feature of all
EJB or only Entity beans.

3. EJB takes care of security, transactions, multithreading, security
protocols, distributed programming, connection resource pooling, and so
on for you. (line pasted from a tutorial).

Connection pooling is done by dataSource in the App Server. How does
EJB do connection pooling.

Security - I understand that the EJB can be hosted on another server,
separate from the DB and the Web server. Is that the security which is
talked about.

Distributed programming - Isnt this what Servlets also do. I mean they
handle concurrent web requests. You can use simple java classes for
business logic, and servlets for redirection/delegation. How is EJB
useful here. Does it mean something like, 5 EJBs on one server, another
5 on second server, and so on.

You can point me to good resources which actually explain how EJB works
and in what scenarios it is useful. Most of the web pages or books I
have read, just give a few paragraphs about EJB advantages, and move
over to serious stuff.

Thanks

 

[Roedy Green]

What does threadsafe mean here.

Thread safe just means two or more threads can call methods on some
object/bean/class with little fear something will go wrong. The
methods are designed to deal with any such contention.

http://mindprod.com/jgloss/threadsafe.html

 

[Roedy Green]

They say it does transaction management for you. What do we mean by
transaction management here.

The basic concept of a transaction goes back to the CODASYL databases
of yesteryear. You need to make a series of changes to the state of
your system. You proceed and part way through your updates, you
discover you can't continue for some reason. You just say Scuzzi and
the WOMB looks after backing out the changes you made up to that
point. So each group of changes is called a transaction. At the end
you COMMIT and make the changes final.

Transactions may be logged. Then if you crash, you can restore a
backup system, and replay the transactions to bring it up to the state
it was moments before the crash, discarding any partial transactions.
I don't know if EJBs do that. But certainly the transaction systems in
pre Java days did.

Think of the EJB womb as like a database kept mostly in RAM, that is
backed by an SQL database for overflow. That would not be an accurate
description of an desktop toy EJB, but it might describe a how a major
corporation would use it. They just throw RAM at problems still nearly
everything of importance is in RAM either in the EJB womb or the SQL
engine cache.

 

[Roedy Green]

3. EJB takes care of security, transactions, multithreading, security
protocols, distributed programming, connection resource pooling, and so
on for you. (line pasted from a tutorial).

In the olden days of the Burroughs 1900 there were things very much
like Java Servlets used for transaction processing. I would guess
EJBs borrow some of that well tested architecture.

Your programs communicated by pipes in a sort of assembly line,
passing messages along doing a little processing on them, such as
database lookups. Queues would form behind some programs. The control
program would notice this and spawn new logical copies of these
programs to help deal with the backlog. Code was reentrant, so this
would be much like creating another bean instance would be today.

The hardware had only 2MB of RAM, but the code was very compact. You
could crank out a heck of a lot of transactions through this tiny box.
The competing architecture of the day was something like CGI where you
loaded code afresh to deal with each transaction stage. These servlet
things ran in a loop maintaining their own context and caching reading
work to do messages on one set of pipes and directing output out
another. You plugged the pipes together like a set of plumbing to
create the system.

Perhaps someone familiar with EJB could tell us just how similar that
is.

 

[Roedy Green]

Code was reentrant, so this
would be much like creating another bean instance would be today.

that just means if you have two logical instances of a program, you
need only one copy of the code shared between them. Today, all Java
code is written that way automatically.