geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Quintin Beukes <quin...@skywalk.co.za>
Subject Re: The need for pooling beans
Date Wed, 04 Nov 2009 18:12:28 GMT
I'm not sure I understand your question?

But why to use bean pooling for a Session Facade (implemented with a SLSB)?
> We can't assure that two clients using the same method of a service bean
> will bring problems.


Which is why you're only allowed one bean per request. This way you can rely
on the variables not being changed by another thread.


> In fact, that's the idea behind servlets: only one
> instance per servlet. Clients use the same servlet instance at a time.


That's because servlets are unmanaged components. You have to use the
different servlet contexts to process the request into a response, ex. the
SessionContext. It's a much older spec and designed to be free/flexible.

The EJB spec on the other hand was designed to be managed components. Many
resources can be injected into a bean which are building blocks for JavaEE,
some of which might not allow concurrent calls themselves, you can't know
for sure so it's a general policy to not allow concurrent calls on the same
instance. Pooling the SLSBs ensures that the request can be processed and
it's members won't be accessed concurrently. The container can guarantee
safety for both thread safe and non thread safe resources if it uses this
policy. EJBs also provide managed transactions, which won't be possible if 2
concurrent calls were to use the same injected DB connection. There are many
reasons, all related to concurrency in some way for why SLSBs are pooled.

With a servlets these things are all responsibilities of the developer, ie.
servlets are unmanaged. I guess one reason for this is because servlets were
made for a protocol which is much older, ie. HTTP. So to stay compatible
with and provide all the functionality available to it they left the
developer with this freedom. To ease this burden many people have written
frameworks to follow a chosen design, and effectively making managed
components.out of your webapp components.

Of
> course there will be cases where it's good to ask for a new instance of a
> bean (or create it or whatever), for example, when we know we have
> not-shareable resources, like an instance variable that is a DB connection.
>

The container manages this for you. This is another example of why SLSBs are
pooled. If you want fine grained control over the life cycle of your
components, you can use SFSBs or use an alternative system inside the SLSB,
like Spring beans or an instance manager component which your SLSBs query
for instances of the component.


> But that's not to assume that EVERY SLSB has to be pooled. It may bring
> more
> handicaps than advantages...
>
>
This is true. Many people have simple SLSBs which would work just as well,
if not better when there is only a single instance with no concurrency
control, which is what was addressed EJB3.1 resulting in the Singleton EJB
(annotated with javax.ejb.Singleton).

Does this answer your question?

Q

Mime
View raw message