Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

caching business delegate reference  RSS feed

 
Mark Lybarger
Ranch Hand
Posts: 72
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
we're currently implementing business delegate/session facade on our system. currently, we have a business delegate factory which just returns new instances of the business delegates for the clients to use. when each business delegate is instanciated, they create a new instance of a service locator. each business delegate instance holds a reference to the remote component interface it uses. that reference is obtained during construction.
my thought is that all this object creation could be costly in a system that needs performance squeezed out of it. is it common or plausable to cache the business delegate references (effectively the remote component interfaces) so that there's effectively one per client application (webapp)? what are the drawbacks to doing this? i've seen the service locators caching the home interface, for beans, and the delegates caching the remote component interface, but it seems that it may be nice to have the delegate themselves cached if it makes sense.
i had posted this to the OO, patterns and UML group and they directed me here.
thoughts?
 
Kyle Brown
author
Ranch Hand
Posts: 3892
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think you'd be wasting your time in caching the business delegates. If you have a performance problem, then use a real performance profiling tool and find out where your bottlenecks are. Don't fix something that ain't broke.
Kyle
 
Jason Stull
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We run in to the same problems. It's all the overhead of creating a client's instance of the webapp. Business Delegates, Service Locators, JavaBeans, etc.). One thing we have tried is to pool webapp instances. The problem with this is that you have to handle initialization and cleanup for all the object instances hanging around in the cached webapp. This could be done ejb fashion where at some point the pool and all it's webapp instances are initialized. When a client reqeuests a webapp instance from the pool it is ready to go. When the webapp instance is returned to the pool it is reinitialized to a usable state for the next client.
 
Ade Barkah
Ranch Hand
Posts: 65
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We've cached business delegates in the past... I'm not convinced it was worth the hassle.
Remember that the J2EE container might (unknown to you) associate some context into the thread's local storage at various times (eg., when obtaining an InitialContext, doing a JNDI lookup, or calling a bean method.) For example, the container might put the current security principal on ThreadLocal. Another use might be to note the cluster's server affinity.
If too much is cached, then the container doesn't refresh this information as it normally would, and the next client runs on the thread with stale data. The results could vary from annoyance (calls randomly fail, clusters don't balance properly) to disastrous (beans being called with the wrong security context.)
It's doable, but one must really understand what the appserver is doing. As Kyle says, do some profiling instead and find out where the real bottlenecks are.
-Ade Barkah
 
Rick DeBay
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Mark Lybarger:
[snip]
When each business delegate is instantiated, they create a new instance of a service locator.
[snip]
My thought is that all this object creation could be costly in a system that needs performance squeezed out of it.

Make the Service Locator a Singleton.
Rick DeBay
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!