tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Quintin Beukes <quin...@skywalk.co.za>
Subject Re: Question regarding Stateless session beans
Date Sat, 14 Nov 2009 09:37:31 GMT
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.blevins@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.
>>
>>
>
>

Mime
View raw message