• Post Reply Bookmark Topic Watch Topic
  • New Topic

Stateless Session Bean performance

 
Gus Winds
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am involved in a refactoring of a huge Session Bean. For coding managing purposes, i am planning to break into a logical 3 Stateless Session Beans. Are there any runtime performance issues that i need to worry about going from 1 Mega SLSB to 3 SLSB's.
 
Alex Sharkoff
Ranch Hand
Posts: 209
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Gus,

As you're just putting some methods that were exposed in your mega bean's component interface into the component interfaces of your other two sbs then there will be no performance hit.
The callers of the methods will have to just do a jndi look up for a different bean rather than going through the Mega sb (therefore you do not lose any performance in this area, all the rest things are the same for slsb)


[ October 21, 2004: Message edited by: Alex Sharkoff ]
 
Gus Winds
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thx Alex, thats what i had guessed myself. However, it might be that in some cases, the client might have to invoke two different SLSB's because two different methods which were under the same bean now exist in two different beans. Of course, this depends how effectively i am able to carve two SLSB's out of the parent so that each client still invokes one bean.
 
Pradeep Ram
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Gus,
When you refactor the code try to keep the interfaces as distinct as possible between the 3 SLSBs that you are going to create. Effectively, the load will be balanced amongst the 3 beans.

I am not sure if you have any transactions associated with the SFSB. If you do, how you decide to split the transaction amongst the new beans will be a good place to watch for potential problems.

Just curious, if you had a SFSB earlier, how are you planning to store state based information in the SLSBs ?
 
Gus Winds
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thx Pradeep for your tips. The existing Session Bean is Stateless as well so i dont have to worry about maintaining state. The problem is the Bean is huge ( 15000 lines of code ) with lot of what looks like duplicate code. the methods are huge and difficult to manage. Performance wise, i am planning to run through the profiler to identify which methods are slow performing.

Some of the methods are requiring New transactions; i do need to keep those in mind before i split them out.

I was wondering if moving some of the code to helper classes might help. Anyone had an experience with that ?
 
Brian Tinnel
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Something else to be careful of... If one method calls another in the mega SLSB and you change it so that it needs to call one of the other SLSB then you could have transactional mixups.

For example, if MethodA calls MethodB and both are set as RequiredNew, there is only one transaction created, namely the one for MethodA. That is because calls from one method to another are not intercepted by the container. However, if you move MethodB to a different SLSB, then you call will not be a simple MethodB() call but rather slsb2.MethodB(). In that case, a new transaction will be created. This has both performance and functional implications.
 
Pradeep Ram
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have done a similar implementation of refactoring 'magic sfsb'. But in my case, there was only one transaction. I had written POJO (helper) classes for such a scenario, where the funcitonality (processing) was delegated to helper classes to keep the bean code cleaner. I wouldn't say we achieved significant performance increase, but the purpose of refactoring was to increase reusability.

We had reduced 1 sfsb to 2 slsb, and we had chained the slsb for some of the requests. I am not sure if you can chain your requests, but keep the methods that are involved in the same transaction within a single bean.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!