home.create and ejbCreate

In the book Mastering Enterprise Java Bean 2nd Edition by Ed Roman,
it says the create and remove methods of a Home Object is responsible for
create and remove EJB Object. They are called by clients.
The ejbCreate and ejbRemove methods are implemented in the Bean class,
and called by container. The bean instance will be created or removed
by these two methods.

When a client call create and remove methods on a Home Object, the
bean instances are not necessarily be created or removed, because the
container may caching some method-ready bean instances. The container
will control when these bean instances should be created or reomved.

My question is "is this true"?
Because in all the EJB examples, I saw the ejbCreate or ejbRemove
were always called when client called a Create or Remove home method.
I am wondering if the Home.Create and Home.Remove are actually
bonded with ejbCreate and ejbRemove methods?

Anyone had experience with this?
Thanks.

dolphinn wrote:

> In the book Mastering Enterprise Java Bean 2nd Edition by Ed Roman,
> it says the create and remove methods of a Home Object is responsible for
> create and remove EJB Object. They are called by clients.
> The ejbCreate and ejbRemove methods are implemented in the Bean class,
> and called by container. The bean instance will be created or removed
> by these two methods.
>
> When a client call create and remove methods on a Home Object, the
> bean instances are not necessarily be created or removed, because the
> container may caching some method-ready bean instances. The container
> will control when these bean instances should be created or reomved.
>
> My question is "is this true"?
> Because in all the EJB examples, I saw the ejbCreate or ejbRemove
> were always called when client called a Create or Remove home method.
> I am wondering if the Home.Create and Home.Remove are actually
> bonded with ejbCreate and ejbRemove methods?

This is container dependant. In general a home.create() call by the
client can cause an ejbCreate() on the bean but there is no must. Bean
configuration issues also influence this behaviour.

-marek