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 Sat, 07 Nov 2009 12:04:39 GMT
We're missing each other here. What I'm trying to explain is justifications
for why it's there in the first place, and some general ideas behind the
motivations for each - at least from my PoV.

Regarding why pooling is there. Sure it's not needed in all the cases. But
for the design to work for all cases it was placed there. In some situations
concurrent calls are absolutely forbidden, and it's impossible for the
container to know this without adding extra complexity. So they make pools.
An alternative would be to create new instances, but what if creating an
instance is a heavyweight operation? So they pre-create them and add them
into a pool. Now everyone can be served from the same platter.

Assume it would take 500ms to 1000ms to create an instance, and the logic of
the bean is complex with multiple this.calls() and member variables being
used so concurrency isn't possible on an instance, and you're serving many
requests per second. A pool is very useful for such a situation.

In the end there is no harm in a pool. It might just be more optimal without
it for some (or even most) cases.

To try and explain it a bit simpler. Lets say you were designing an
application and a requirement was to pick a one-size-fits-all design. A
given is that it will be used in threaded and non-threaded environments. A
thread safe design will work for both threaded/non threaded scenarios. A non
thread safe design will work only for non threaded scenarios. So which
design would be best, thread-safe or non-thread-safe? Obviously the
thread-safe?

Or a more natural world (though stupid) example. You have to serve food to
group of people and keep everyone happy. You're not sure if some people
might be offended by eating meat. So you make a tasteful green meal, because
"meat eaters" aren't offended by eating greens.

Now, just like you say the pooling is needed in the rarest of cases. It's
true. I've only had a single case ever where multiple SLSB instances were
truly useful/needed. So Singletons were born for the rest of the scenarios,
and they will most probably become the most used EJB (after entities, though
IIUC entities  technically aren't EJBs anymore). In my current project I'm
using only 1 SFSB, 1 SLSB and a whole bunch of Singleton beans. Why? Because
I need only one instance of each and concurrency is not an issue.

Regarding why we were so "lucky for having pools". I guess it's because of
the benefits it does have for the more complex scenarios. Remember that EJBs
were designed for solving complex enterprise system problems. So this
statement was probably made keeping in mind those problems.

Quintin Beukes


On Fri, Nov 6, 2009 at 1:07 AM, Antonio ForniƩ <sitaronocturnal@gmail.com>wrote:

>
> Yes, it does! Thank you! It was not just a question but also an opinion.
>
> Sometimes I need transaction and security (so I need EJB according to Sun),
> but I'd prefer not to have pooling. If I only needed a Singleton I could do
> it by myself but it wouldn't be an EJB, so yes, sometimes I need this new
> Singleton EJB that's about to come.
>
> In fact, I think by and large we don't need pooling so, prior to EJB 3.1,
> is
> it a good idea to use EJB  for all my Bussiness Objects or only for a few?
> That's what I'm pointing out. I'm not sure about that general need for
> pooling... even when Sun and App Server vendors are so proud about their
> bean pools, it doesn't mean I need it.
>
>
> On the other hand I don't see why you say:
> >> That's because servlets are unmanaged components.
> As far as I see this has nothing to do. I insist, Spring showed everybody
> we
> can live without pooled beans, and it's even better for the 90% of times.
> Managed or unmanaged components. In fact future Singleton EJBs will be
> manged components too.
>
>
> >>Spring might not have pooling, but this isn't necessary on the client
> side.
> I'm afraid I don't you what you mean. Please, why do you talk about the
> client side? I only say that most of the times we don't have any problem if
> different threads or even different clients are using the same object at a
> time. In a near future we'll have Singleton EJB, but for many years we've
> been told how lucky we were to have pooled beans... for so many years this
> was not the way (except for a few cases). Don't you agree?
>
>
> >>The container manages this for you. This is another example of why SLSBs
> are pooled.
> Yes, this is why they say they pool SLSBs, but the problem is that it's not
> needed. Spring manages for you access to objects (by IoC) and it doesn't
> mean that those objects should have been pooled. Of course it's good to use
> pools in some situations, but when you follow the Sun official path (for
> example, if you want to study for the Sun Certificate Enterprise Architect
> as I'm doing) you are told that for any application big enough not to use
> only Servlets/JSP you need an EJB container. And you read the J2EE Core
> Patterns and you may end up believing you need pooled beans for a Session
> Facade and similar cases... do you think that's true? Thounsands of Spring
> applications use singletons even for DAOs. I may be missing something, but
> as far as I can see it's like using a Ferrari to go to the bathroom. But
> please, I really think there's something I must be missing and I'd like to
> be taught.
>
> Sorry if I talk about Spring, it's because it's the most famous
> alternative.
> Thank you very much!
> --
> View this message in context:
> http://old.nabble.com/The-need-for-pooling-beans-tp26156648s134p26223990.html
> Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
>
>

Mime
View raw message