Thanks Quintin for sharing your experience.
Actually I can't use processAll(). In normal cases the processAll() would
work but in some cases I need to do something else between those three
methods and processAll() can't be the right way
Creating session keys requires to involve more complexity and I think I use
Statefuls instead
Quintin Beukes-2 wrote:
>
> Just in case you're not aware of this, if you're done with the
> stateful, you can destroy it with an @Remove method.
>
> Other alternatives could be to wrap those calls into a single call like
> this:
> sessionBean.processAll() and inside sessionBean call pre/process/post.
>
> I had a similar case with Glassfish appserver, where the stateful
> beans were very slow and the server became unusable. I would do
> different calls to the bean during the course of processing some data.
> This required a lot of back/forth between the server and client. So
> what I did was to change to stateless, and added a static field in the
> stateless bean, which was a Map<Integer, MyStateObject>.
>
> The first call to the bean was:
> int sessionKey = sessionBean.createSession();
>
> I would store the session key and then all other calls would do something
> like:
> sessionBean.doSomething(sessionKey);
> ....
> sessionBean.doSomethingElse(sessionKey, arg1, arg2);
>
> They would use the key to retrieve the object, and invoke the actual
> logic on these methods. Any injected fields would be passed into the
> object on every invocation (they aren't actually stored in the state
> object).
>
> And when I'm done release the resources with:
> sessionBean.destroySession(sessionKey);
>
> Also, to avoid memory leaks I had a scheduled task which would clean
> up old sessions which might have been left over from crashed sessions.
>
> This isn't a nice way to do it, and I would rather use a Stateful bean
> for this anytime. Though, like I mentioned the overhead became too
> large. I would definitely try OpenEJBs stateful beans first, and
> resort to an alternative when you need to. Personally I don't think
> you will. OpenEJB is fast and lightweight. In the past few weeks I've
> redone one of our Glassfish applications, and it's currently running
> like a 100% local application. You don't even NOTICE the overhead of
> EJB calls. I don't think I'll have problems deciding on an application
> server/container in the near future.
>
> Quintin Beukes
>
>
>
> On Thu, Nov 12, 2009 at 8:13 PM, David Blevins <david.blev...@visi.com>
> wrote:
>>
>> On Nov 12, 2009, at 5:09 AM, Jean-Louis MONTEIRO wrote:
>>
>>>
>>> Stateful uses some more complex mechanisms. So i imagine there is an
>>> overhead.
>>> I never did any benchmarks using stateful with 5000 virtual users. May
>>> be
>>> David can give us some hints?
>>
>> There's not too much overhead with the stateful bean itself, but there
>> can
>> be an unlimited amount of overhead in the data held by the stateful
>> bean's
>> fields. So how many you can have at one time is limited by what objects
>> the
>> stateful beans are referencing, the size of those objects, and the amount
>> of
>> memory.
>>
>> Also as a general Stateful bean note. Make sure you have an @Remove
>> method
>> and use it aggressively to discard your Stateful bean when you are done
>> with
>> it.
>>
>>
>> -David
>>
>>
>>>
>>> is_maximum wrote:
>>>>
>>>> Thanks, do you know if there is any overhead using stateful SBs? And
>>>> does
>>>> this degrade the performance?
>>>> There are many such services and in real word our application may serve
>>>> more than 5000 users.
>>>>
>>>>
>>>>
>>>> Jean-Louis MONTEIRO wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> In my opinion you are not guaranty to get the same instance of a
>>>>> stateless session bean between invocation (a stateful is better for
>>>>> that).
>>>>> In OpenEJB the bean instance is retrieved from the pool at the
>>>>> beginning
>>>>> of the invocation and returned to the pool at the end of the
>>>>> invocation.
>>>>>
>>>>> Jean-Louis
>>>>>
>>>>>
>>>>> is_maximum wrote:
>>>>>>
>>>>>> Hello
>>>>>>
>>>>>> We have a stateless SB with three method: preProcess, process and
>>>>>> postProcess
>>>>>> Normally when I use this EJB in another SB I call these methods as
>>>>>> follows:
>>>>>>
>>>>>> public class AnotherEJB {
>>>>>>
>>>>>> @EJB
>>>>>> private SessionBean sessionBean;
>>>>>>
>>>>>> public void someMethod() {
>>>>>> sessionBean.preProcess();
>>>>>> sessionBean.process();
>>>>>> sessionBean.postProcess();
>>>>>> }
>>>>>>
>>>>>> }
>>>>>> this works fine and it seems the state of that bean is kept the same.
>>>>>> My question is if a delay occurs between these three methods, will
>>>>>> container assign this stateless to another thread to serve incoming
>>>>>> request and after this delay say process() method is called it might
>>>>>> be
>>>>>> another session bean instance? To clarify my question look at
>>>>>> following
>>>>>> code:
>>>>>>
>>>>>> public void someMethod() {
>>>>>>
>>>>>> sessionBean.preProcess();
>>>>>>
>>>>>> //calling another method which takes too long to complete, and
>>>>>> during this method container
>>>>>> // is receiving another request in which sessionBean is invoked
>>>>>> doSomethingMassive();
>>>>>>
>>>>>> sessionBean.process(); //is this the same instance of sessionBean
>>>>>> that already invoked preProcees() method above?
>>>>>>
>>>>>> perhapsDoSomethingElse(); //another method
>>>>>>
>>>>>> sessionBean.postProcess();
>>>>>>
>>>>>> }
>>>>>>
>>>>>>
>>>>>> can anyone please help me on this?
>>>>>>
>>>>>> }
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://old.nabble.com/Question-regarding-Stateless-session-beans-tp26315274p26318347.html
>>> Sent from the OpenEJB User mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>
>
-----
--
Regards
Mohammad Norouzi
Help each other to reach the future faster
http://pixelshot.wordpress.com Pixelshot Photoblog
http://brainable.blogspot.com Brainable Blog
--
View this message in context:
http://old.nabble.com/Question-regarding-Stateless-session-beans-tp26315274p26356074.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
