Head First EJB

Bean Creation: when an object becomes a bean

setSessionContext() and ejbCreate() happen only once in a session bean’s life, so don’t blow it! And don’t try to do things too soon... the constructor is too early to do any bean things.

A bean moves from does not exist to method ready (still feels creepy... doesn’t it have to exist before it can move?), beginning with a constructor. But the constructor makes an object, not a bean. To be a bean, the object needs to be granted beanness.

When an object becomes a bean, it gets all the unique privileges that come with beanness, like the ability to get security info about the client, or look up special deploy-time properties in the bean’s special space in JNDI, or get a JDBC Connection from a pool managed by the container.

Why do you care about creation details?

Because somewhere between the constructor and the create() method, the bean is in a Schroedinger’s bean^[8] state. You might have bean initialization code, like getting a JDBC Connection, or looking up a reference to another bean, that will fail if you run it too early in the bean’s life. Writing good bean code means you must know the point at which an object becomes a card-carrying bean and what that means to you as the developer.

What does “beanness” buy you?

What happens when a bean goes from this:

to this?

1. A SessionContext reference

   A bean’s context (sometimes called EJBContext, referring to the superinterface of SessionContext) is the bean’s only lifeline to the Container, and it lets the bean do things like get security information about the calling client, force a transaction to rollback, get a reference to the bean’s own home or EJB object, and more.

2. A special JNDI Context

   Every bean gets its very own JNDI context, where it can find things including resource manager connection factories (objects that give you connections to resources like a database), other beans, and deploy-time constant values that you can use to customize your bean’s variables. You’ll learn a lot more about that in Chapter 11, where we look at the enterprise bean environment (that’s what the spec calls the bean’s special JNDI context).

3. Access to beans and resources

   Just because you got a connection to a database doesn’t mean you can always use it. Part of being a bean is the ability to access a resource (like a database) or call methods on another enterprise bean.

Note

Don’t confuse a bean context with a JNDI context!

Just when you thought it was all so clear, you find to your horror that the word “context” is overloaded!

A bean’s context, like SessionContext (or EntityContext or MessageDrivenContext) is the bean’s special reference (which extends EJBContext) for getting info from the Container.

This has NOTHING to do with a JNDI context. A JNDI context, remember, is a particular “node” on a JNDI virtual directory tree. An InitialContext is the JNDI context that serves as your entry point into the tree structure. In other words, the place from which you start navigating through the tree.

Whenever you see the word “context”, look closely at the, um, context of the question to figure out to which context the question refers—the bean’s EJBContext or JNDI context. Sheesh!

Special Bean Things

1. A SessionContext reference

   Things you can do with your context:

   • get a reference to your home

   • get a reference to your EJB object

   • get security information about the client

   • force a transaction to rollback (CMT)

   • find out if the transaction has already been set to rollback (CMT)

   • get a transaction reference, and call methods on it (BMT)

   

2. A special JNDI Context

   Things you can lookup with your special JNDI context:

   • a reference to another bean

   • a reference to a resource manager connection factory (like DataSource) that you can use to get, for example, a database connection

   • deploy-time constant values (kind of like properties) for the bean (values set by the deployer that the bean can look up and use as variables at runtime).

   • a reference to an “administered object” resource (which usually means a JMS destination)

   

3. Access to...

   • another bean

   • a resource manager (like a database)

   

You can’t always use all of your beanness...

Just because you’ve become a full-fledged bean doesn’t necessarily mean you can do all of the Bean Things on the opposite page (lookup a resource, force a transaction rollback, etc.).

The things you can do can vary depending on what kind of bean you are (Session, Entity, MessageDriven), your transaction status, and what kind of method you’re in.

For example, if you’re a stateful session bean, your creation is a direct result of the client calling create() on your home. If you’re a stateful bean, and you’re in your ejbCreate() method, there can be only one reason: a client has asked for you to be created. And that means you can find out who the client is, by asking your EJBContext (like SessionContext) for client security information.

But if you’re a stateless bean, your creation isn’t tied to any particular client’s request (you’ll learn all about this in a few more pages). In fact, if the Container wants to, it can create a bunch of stateless beans for the pool before there are any clients. And that means a stateless bean cannot get security information about the client during ejbCreate(). Because there’s no client! There’s only the Container, invoking a container callback that’s not part of a client call, and we don’t consider the Container to be a client. The Container is the boss, not the client.

And there are some Bean Things that can be done only while the bean is in what the Container considers “a meaningful transaction context.” You can’t, for example, access a database from a method that might not have a transaction.

Some Bean Things are mutually exclusive. If you’re using container-managed transactions (CMT) (Chapter 9), you must not ask your EJBContext to give you your own transaction object. On the other hand, if you’re using bean-managed transactions (BMT), you can ask for a transaction object, but then you must not ask your context to rollback your transaction. You’ll have to rollback the transaction yourself, using the transaction object you got from your context.

Note

You must know WHEN you can do specific Bean Things and when you can’t.

Be prepared for code or a scenario, that shows you a method and asks whether you can do a particular Bean Thing from that method, given the circumstances.

For example, you might be shown the setSessionContext() method of a bean, and asked if you’re allowed to access a resource (like a database) from that method. (You’re not! You aren’t in a “meaningful transaction context” at that point.)

Bean creation overview

(stateful session bean)

1. Client calls create on the home

   

2. Container makes the EJB object and SessionContext

   

3. Container constructs the bean instance

   

4. Container links the bean to its context and EJB object (calling setSessionContext() and ejbCreate())

   

   The linking happens when the container calls setSessionContext() and ejbCreate() on the bean. Once ejbCreate() returns, the bean is ready for ‘active duty’ (in other words, ready for business method calls from the client).

5. Container sends the client a stub to the EJB object.

   

Object Interaction Diagram (OID) for bean creation

(stateful session bean)

Relax

You don’t have to know UML to pass the exam!

The exam doesn’t require you to know UML, although a little UML is in the EJB spec. Some of our best friends don’t know UML. It’s nothing to be ashamed of. Really. However, if you are one of the ten remaining people who in fact do not know UML, and you don’t want to risk public humiliation and ridicule, you might want to consider our Head First UML & Patterns book (2004).

Writing the three creation-related things

(stateful session bean)

1. constructor

   Don’t put anything in the constructor! There’s nothing you would do in the constructor that you can’t do in ejbCreate(), so unless your IDE puts one in for you, you’re better off leaving the constructor out of your code.

   

2. setSessionContext(SessionContext sc)

   Save your context! You get only one chance to grab this reference to your SessionContext, so you better assign it to an instance variable.

   

3. ejbCreate()

   Put all your initialization code here! If it’s a stateful bean and the create() method has arguments, the Container will pass those arguments into your matching ejbCreate() method. You have full bean status now, so you can do anything you need to from this method, including things you can’t do in setSessionContext() (like get a reference to your own EJB object).

   

---

^[8] We’re not explaining the whole Schroedinger reference here, except to say that it involves cats (animal-lovers be warned) and subatomic physics. For more info, look for Head First Quantum Physics in the future. We’re serious. Serious for us, anyway.