Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

caching remotes instead of homes in weblogic  RSS feed

 
Ivan Rublev
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Could anybody provide some input on how reliable it is to cache stateless session beans remotes instead of homes in weblogic 6.1. I'm aware that this is not EJB-compliant and by its nature is a hack. In our case, it proves to increase performance in some of the scenarios so I wanted to see if this approach works well in production. The call to "create" on the bean home seems to be quite costly.
ServiceLocator and the likes talk only about caching homes. If the only concern, when caching stateless session beans remotes, is clustering and replica-aware remotes then I can live with that. On my tests, it seems to work fine on WebLogic 6.1, although I haven't tested it yet in a highly concurrent environment.
Thank you
 
Chris Mathews
Ranch Hand
Posts: 2712
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is not a good idea. You may be undermining WebLogic's ability to manage its instance pool and quite possibly limiting your system's concurrency by doing so (since the EJB Container is tasked with thread management), depending on how WebLogic implements their EJBObjects. Obviously, this behavior is very dependent on the implementation. Even if it works are you sure you are willing to make the sacrifice for a small performance gain? Not only would you be limiting your portability to other J2EE Servers, but you would be limiting it to other versions of WebLogic. What if WLS 7.0 handles this situation slightly different? What about WLS 8.1? Doesn't seem like a good trade-off to me...
Regardless, I am having a hard time imagining that retriving a Remote reference to an EJB is a huge bottleneck in your system. Are your calls remote or can they be switched to local interfaces? Have you profiled to see where your actual performance hit is occuring? Is performance good enough? If so then, don't optimize for the sake of optimization. If not, then do you at least have some type of performance goal that you are trying to meet?
I have a feeling that there is a high possibility that you could make greater performance improvements elsewhere in the system without sacrificing reliability and portability.
 
Chris Mathews
Ranch Hand
Posts: 2712
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
BTW, in the future please avoid cross-posting the small question to multiple forums.
 
Ivan Rublev
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As you probably noticed, I wasn't asking for the general introduction to how EJB container works and how to make things portable. I specifically highlighted that I was aware of non-portability of this approach and I do know that it is container-specific. That's why, I wanted to know was whether this approach would work on WL 6.1. It is a temporary solution until part of the legacy code is refactored and better implementation is introduced.
 
Dana Hanna
Ranch Hand
Posts: 227
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If your only goal was to find out if it worked, hadn't you done that already??? You say that you tried it successfully, and that is boasted a performance gain. You are interested in knowing if it will work in production...
It sounds like you are looking for someone to approve your "hack". Why not use the container as it is meant to be used? We have not heard of this problem of the create method in WebLogic 6.1 before, so explain more thoroughly!
Imagine caching Connections received from a DataSource instance. While it may ammuse you, it doesn't provide anything.
Maybe the serialization overhead is catching up with you. If that is the case, let us know! Use a profiler to identify the true problem.
[ August 22, 2003: Message edited by: Dana Hanna ]
 
Ivan Rublev
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you haven't heard of a problem, that doesn't mean that the problem doesn't exist. While it may amuse you, I had an eightfold improvement in throughput because of this "hack".
For the record, there has always been a big disconnect between good performance and portable code. It's even more true for ejb spec...
 
Dana Hanna
Ranch Hand
Posts: 227
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I understand that hacks are needed - but it's always better if you understand why you are hacking. I would inject a performance monitoring tool (like Borland's OptimizeIt) to find the hangup in "create". Short of that - decompiling using JAD has helped me find many orkarounds for WebSphere and it's EJS.
 
Ivan Rublev
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
While profiling the application, I sampled a bunch of thread dumps over the period of the client-demarcated transaction on the WL server. Most of the time was spent in serializing/deserializing (!) transaction context object on the server side on every "create" call. Which is not the same as propagating transaction id or Xid with every remote call.
Of course, the best solution would be to go and reconsider distribution boundaries and have better transaction management in the legacy code. However, there was no time for a change this big...
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!