Head First EJB

SessionContext

You need it more than it needs you

At the beginning of a bean’s life, and only once in the bean’s life, the Container calls the bean’s setSessionContext() container callback method.

That context (a subclass of EJBContext) is the bean’s lifeline to the Container, and it’s the only thing the bean can call methods on to get references to his own home and EJB object, to get security information about the client, or to do transaction-related things. We won’t look at the security and transaction info now; they’re both covered in separate chapters.

Note

Memorize the SessionContext interface!

You must be able to look at a list of methods, and know which belong to the SessionContext interface. And remember, a lot of the questions related to lifecycle are about knowing the methods from which you can call certain methods on your context. For example, you have to know that you can’t get client-related info from your context in the ejbCreate() method of a stateless bean. Because there’s no client associated with a stateless bean’s ejbCreate()! But you CAN get client info from your context from a stateful bean’s ejbCreate(), because a client initiated it.

Things you can do with your SessionContext (9 methods, 4 categories)

	get a reference to your home getEJBHome() getEJBLocalHome()
	get a reference to your EJB object getEJBObject() getEJBLocalObject()
	get security information about the client getCallerPrincipal() isCallerInRole(String s)
	force a transaction to rollback (CMT only) setRollbackOnly() find out if the transaction has already been set to rollback (CMT only) getRollbackOnly() get a transaction reference, and start your own transaction (BMT only) getUserTransaction()

Relax

You don’t need to know the three deprecated methods.

Besides the ones shown on this page, the EJBContext interface has three other methods, all of which have been deprecated. You’re not tested on deprecated methods, so if you see them in the API, don’t panic. The only reason you need to know about them is in case you’re working with older EJB code. The methods are:

isCallerInRole(Identity id)

getCallerIdentity()

getEnvironment()

Overheard at the Tikibean Lounge

Stateless bean: I don’t see how you can stand it, being a stateful bean. Your whole life is tied to servicing one client.

Stateful bean: I’m not sure I like the way you phrase that, “servicing one client”. Makes it sound like I’m a personal slave, or something.

Stateless bean: And that would be wrong because...

Stateful bean: It’s a personal, intimate relationship. A relationship that you couldn’t possibly comprehend.

Stateless bean: What is THAT supposed to mean?

Stateful bean: Because your relationships are so... transient. You don’t really care WHO you service. Any client in a storm, as they say.

Stateless bean: There’s nothing wrong with that. I’m a people person. I like being in the pool with the other beans, then constantly meeting new clients. It’s never boring, and I barely ever see the same client twice and—

Stateful bean: My point exactly! You’re not even PHYSICALLY able to sustain a meaningful, ongoing relationship.

Stateless bean: Excuse me?

Stateful bean: It’s that short-term memory loss thing. You can’t hold any client information between method calls, which is why it doesn’t matter WHICH client calls. You’d never be able to remember even if you got the same client calling ten of your methods in a row.

Stateless bean: Yeah, but that’s not a problem. Remember, I’m used for services that don’t NEED me to remember anything from clients between method calls.

Stateful bean: Which is also why you’re not used for anything big or serious.

Stateless bean: Now wait just a minute here—that is SO not true! In fact, if you want to talk performance, buddy, I’m way more scalable than you. And before you start arguing, don’t even give me that nonsense about passivation. I’ve heard all the arguments. But passivation will NEVER make you as scalable as me.

Stateful bean: OK, maybe I’m not quite AS scalable... but there are more important things in life to consider.

Stateless bean: For example?

Stateful bean: Well, I’m easy to use. Easy and quick to build. Maybe that’s more important to the developer. And in some cases, I’m still gonna perform better, when you really do need client conversational state. The options can really suck sometimes... having to store the state in a database with each call (and then go and look it all up again with the very NEXT call)? I know sometimes you have to do that, but still. Or, sure, you could just keep sending the conversational state back to the client so that they can turn around and send it back to YOU with each call and—

Stateless bean: What’s wrong with that?

Stateful bean: Here’s a new word for your vocabulary... “bandwidth”. Pronounce it with me... “baaandwiiiidth”. Do you really want all that going back and forth?

Stateless bean: Ok, yeah, got it. But tell me, how is this worse for performance than the hit from passivation/activation? And while we’re at it—wait, did you hear that? I think I hear your client calling. And it sound like... no... wait... yes... I’m afraid it sounds like he’s calling remove(). It’s been nice talking to you. I’ll be thinking about you while I’m out at the pool. Floating on air mattress. Getting a tan. Drinking margaritas with shaved ice. Wow. I LOVE being me.

What’s allowed?

Put a check next to the methods that you can call on your SessionContext, if it’s allowed from the methods in the left column. For example, in ejbCreate() you can get a reference to your home for both stateless and stateful session beans, so you can put a check in the top box in both columns. All of the answers are in this chapter, but try to make your best guess before going back for the answers. You might want to make another one of these yourself, to include JNDI, resource, and bean access.

Bean methods	Stateful		Stateless
	Use your SessionContext to:		Use your SessionContext to:
		get a reference to your home		get a reference to your home
ejbCreate		get a reference to your EJB object		get a reference to your EJB object
ejbRemove		get security information about the client		get security information about the client
		force a transaction to rollback (CMT beans)		force a transaction to rollback (CMT beans)
		find out if the transaction has already been set to rollback (CMT beans)		find out if the transaction has already been set to rollback (CMT beans)
		get a transaction reference, and call methods on it (BMT beans)		get a transaction reference, and call methods on it (BMT beans)
	Use your SessionContext to:
ejbPassivate		get a reference to your home	Does not apply: stateless beans are never passivated.
ejbActivate		get a reference to your EJB object
		get security information about the client
		force a transaction to rollback (CMT beans)
		find out if the transaction has already been set to rollback (CMT beans)
		get a transaction reference, and call methods on it (BMT beans)
	Use your SessionContext to:		Use your SessionContext to:
business methods		get a reference to your home		get a reference to your home
		get a reference to your EJB object		get a reference to your EJB object
		get security information about the client		get security information about the client
		force a transaction to rollback (CMT beans)		force a transaction to rollback (CMT beans)
		find out if the transaction has already been set to rollback (CMT beans)		find out if the transaction has already been set to rollback (CMT beans)
		get a transaction reference, and call methods on it (BMT beans)		get a transaction reference, and call methods on it (BMT beans)