It's a Matter of Context

We talked a bit last time about minimizing trans-network overhead by

keeping remote method invocations to a minimum and, where possible,

combining multiple "set" and "get" functions into single methods.

Furthering the idea of keeping down transaction load, this week we'll

consider the EntityContext class. EntityContext instances can play an

important role in keeping down traffic between clients and the server.

The EntityContext can store, among other things, a stateless session

bean's connection to the database. By doing so, you save the stateless

session bean the hassle of constantly re-establishing the link, and

thereby incurring overhead, with each transaction.

A container instantiates a stateless session bean by invoking the

bean's setEntityContext() method. You can establish all the database

connections here, as well as other stuff you want to maintain across

all transactions. Your code might look like this:

public void setEntityContext (EntityContext ctx) {

// Yadda yadda.

DataSource ds = (DataSource) initial.lookup

("java:comp/env/jdbc/Default");

Connection con = ds.getConnection;

// Yadda yadda.

}

This ensures that ds and con are available across all transactions

performed by this bean, or at least by this instance of it.

As you might expect, setEntityContext has an opposite,

unsetEntityContext(), that's called when the container destroys the

instance. In your unsetEntityContext() method, you should undo

everything you did in setEntityContext() -- releasing database

connections, for example.

What’s wrong? The new clean desk test
Join the discussion
Be the first to comment on this article. Our Commenting Policies