You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by Mansour Al Akeel <ma...@gmail.com> on 2009/12/02 21:14:44 UTC

EJB pooling

I am looking to maintain an object pool, that will be available to
server a request at anytime. If I am not wrong, statfull bean will not
work as it's ot server on request. I need to maintain the info between
these requests. I have to use Entity bean.  Is this correct ?

Re: EJB pooling

Posted by David Blevins <da...@visi.com>.
On Dec 7, 2009, at 3:33 AM, Mansour Al Akeel wrote:

> Thank you all.
> I am reading more about this. I have done some reading before asking
> the question, as I am not expecting the work to be done for me.
> However, just like any new EJB user, the concept was not fully
> comprehended and there was some confusion.
>
> I have used JPA before, but not with EJB (with spring container). I
> realized later that a statefull session is attached and specific to
> the session.
> My requirements will fit with a stateless bean or an entity (but I
> don't need a db), so it will be a stateless.
>
> To make things clearer, I will explain quickly what I am doing. I need
> to simulate the interaction for the some units in an organization
> (Emergency response). The units (initially, police , ambulance, fire
> fighters ), responds and acknowledge and communicate the info they
> receive using messaging.
>
> I thought  EJB and JMS will fit especially with the distributed nature
> of the system (servers represents federates, where units can be
> borrowed ). I was looking to create a pool of Unit (ie, police
> officers ) using stateless beans, where the state is preserved, but
> they are not attached to any session, and their behavior is
> independent from the request (ie, request to generate a report). My
> next question would be, is to find it it's possible to get a stateless
> bean to receive JMS messages and act accordingly !

An MDB is identical to a Stateless bean in it's lifecycle.  Both are  
pooled and don't keep client state and each request/message that comes  
in an instance is selected from the pool more or less randomly.

In terms of alternate ways to keep state, you might check out the bean  
type @Singleton:

   http://openejb.apache.org/singleton-ejb.html
   http://openejb.apache.org/3.0/singleton-example.html

It essentially allows you to keep application scoped data without any  
statics and with nice concurrency options.

Not sure if that fits with your design, but certainly could provide  
options.

Feel free to keep asking questions.  It's no trouble at all.

-David

>
> On Sun, Dec 6, 2009 at 12:04 AM, Ravindranath Akila
> <ra...@gmail.com> wrote:
>> Andy is right Mansour please do some reading on this. EJB 3.x has  
>> Stateful
>> Session Beans, Stateless Session Beans and Entities (NOT Entity  
>> Beans). The
>> Sun tutorial is one of the most simple tutorials you can find on  
>> this.
>> Entities on the other hand, will be explained in any tutorial of  
>> JPA. So to
>> find out about Entities, read a JPA tutorial. This is a very good JPA
>> tutorial http://schuchert.wikispaces.com/JPA+Tutorial+1+-+Getting+Started 
>> .
>>
>> Yes the same Stateful Beans cannot be retrieved across multiple "web"
>> requests unless you store the bean with use of a framework or HTTP  
>> Session.
>> Stateful really indicates "not shared", and "not discarded as long as
>> referenced".
>>
>>
>> On Thu, Dec 3, 2009 at 1:44 AM, Mansour Al Akeel
>> <ma...@gmail.com>wrote:
>>
>>> I am looking to maintain an object pool, that will be available to
>>> server a request at anytime. If I am not wrong, statfull bean will  
>>> not
>>> work as it's ot server on request. I need to maintain the info  
>>> between
>>> these requests. I have to use Entity bean.  Is this correct ?
>>>
>>
>


Re: EJB pooling

Posted by Mansour Al Akeel <ma...@gmail.com>.
Thank you all.
I am reading more about this. I have done some reading before asking
the question, as I am not expecting the work to be done for me.
However, just like any new EJB user, the concept was not fully
comprehended and there was some confusion.

I have used JPA before, but not with EJB (with spring container). I
realized later that a statefull session is attached and specific to
the session.
My requirements will fit with a stateless bean or an entity (but I
don't need a db), so it will be a stateless.

To make things clearer, I will explain quickly what I am doing. I need
to simulate the interaction for the some units in an organization
(Emergency response). The units (initially, police , ambulance, fire
fighters ), responds and acknowledge and communicate the info they
receive using messaging.

I thought  EJB and JMS will fit especially with the distributed nature
of the system (servers represents federates, where units can be
borrowed ). I was looking to create a pool of Unit (ie, police
officers ) using stateless beans, where the state is preserved, but
they are not attached to any session, and their behavior is
independent from the request (ie, request to generate a report). My
next question would be, is to find it it's possible to get a stateless
bean to receive JMS messages and act accordingly !

I am still prototyping, any advice will be appreciated.


On Sun, Dec 6, 2009 at 12:04 AM, Ravindranath Akila
<ra...@gmail.com> wrote:
> Andy is right Mansour please do some reading on this. EJB 3.x has Stateful
> Session Beans, Stateless Session Beans and Entities (NOT Entity Beans). The
> Sun tutorial is one of the most simple tutorials you can find on this.
> Entities on the other hand, will be explained in any tutorial of JPA. So to
> find out about Entities, read a JPA tutorial. This is a very good JPA
> tutorial http://schuchert.wikispaces.com/JPA+Tutorial+1+-+Getting+Started.
>
> Yes the same Stateful Beans cannot be retrieved across multiple "web"
> requests unless you store the bean with use of a framework or HTTP Session.
> Stateful really indicates "not shared", and "not discarded as long as
> referenced".
>
>
> On Thu, Dec 3, 2009 at 1:44 AM, Mansour Al Akeel
> <ma...@gmail.com>wrote:
>
>> I am looking to maintain an object pool, that will be available to
>> server a request at anytime. If I am not wrong, statfull bean will not
>> work as it's ot server on request. I need to maintain the info between
>> these requests. I have to use Entity bean.  Is this correct ?
>>
>

Re: EJB pooling

Posted by Ravindranath Akila <ra...@gmail.com>.
Andy is right Mansour please do some reading on this. EJB 3.x has Stateful
Session Beans, Stateless Session Beans and Entities (NOT Entity Beans). The
Sun tutorial is one of the most simple tutorials you can find on this.
Entities on the other hand, will be explained in any tutorial of JPA. So to
find out about Entities, read a JPA tutorial. This is a very good JPA
tutorial http://schuchert.wikispaces.com/JPA+Tutorial+1+-+Getting+Started.

Yes the same Stateful Beans cannot be retrieved across multiple "web"
requests unless you store the bean with use of a framework or HTTP Session.
Stateful really indicates "not shared", and "not discarded as long as
referenced".


On Thu, Dec 3, 2009 at 1:44 AM, Mansour Al Akeel
<ma...@gmail.com>wrote:

> I am looking to maintain an object pool, that will be available to
> server a request at anytime. If I am not wrong, statfull bean will not
> work as it's ot server on request. I need to maintain the info between
> these requests. I have to use Entity bean.  Is this correct ?
>

Re: [english 100%] EJB pooling

Posted by Andy <an...@orprovision.com>.
I am being serious, go read 
http://java.sun.com/javaee/5/docs/tutorial/doc/ - then come back and ask 
that question again. I will be very impressed if you do!?

On 02.12.2009 21:14, Mansour Al Akeel wrote:
> I am looking to maintain an object pool, that will be available to
> server a request at anytime. If I am not wrong, statfull bean will not
> work as it's ot server on request. I need to maintain the info between
> these requests. I have to use Entity bean.  Is this correct ?
>
>    


____________
Virus checked by G Data AntiVirus
Version: AVA 19.9094 dated 03.12.2009