aspose file tools*
The moose likes EJB and other Java EE Technologies and the fly likes EJB Resource Pooling in Client Application Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "EJB Resource Pooling in Client Application" Watch "EJB Resource Pooling in Client Application" New topic
Author

EJB Resource Pooling in Client Application

dean tomlinson
Ranch Hand

Joined: Jan 31, 2002
Posts: 94
hi,
i am using some ejb's for a backend data base in a web application, and are looking to improve performance by caching the ejb resources.
first of all i connect to the application server which retrieves a context, from which i can lookup the ejb home objects, and from these create ejb stub's.
i have currently implemented a system where i connect to the application server and retrieve the context when the web application starts up (via a servelt that loads at startup). this is then used as a factroy object.
what i was wondering is if i can also create all the ejb home objects when the web application starts up, and add these to my factory too?
is it safe for one ejb home object to be used by multiple clients to concurrently create ejb stubs ?
if not is there any other techniques that might hellp me ?
thanks a lot - dean

Phil Sharp
Ranch Hand

Joined: Nov 08, 2001
Posts: 40
I think you are probably best leaving it to your application server to handle caching.
Application servers themselves are caching EJBs to provide the best performance they can. Look at your application server documentation to find out about its caching method\policy.
As a general point I would not do any performance improvements until I had a working system and a performance problem was diagnosed. The don't fix it if its not broken approach. Generally making optimisations tends to obscure the code and so make it more difficult to support.
If there is a problem then its important to do analysis to find exactly where the bottlenecks. are. I doubt if caching home interfaces will have much effect on the system performance.
Not sure anyway if your plan to cache home interfaces is good anyway, you cannot be sure of the object that is backing the interface as that is application server specific and the application server may be doing something under the covers that makes cachg inappropriate.
In my opinion the best approach is to hold resources for as short a time as possible and rely on the application server to handle caching as it tends to better at it than any code I can write.
Sorry to be such a downer on your idea. Please tell me if you implement it and it has a performance impact as I'm always keen to learn new patterns.
Phil
[ May 03, 2002: Message edited by: Phil Sharp ]
[ May 03, 2002: Message edited by: Phil Sharp ]
dean tomlinson
Ranch Hand

Joined: Jan 31, 2002
Posts: 94
hi phil,
i'm not sure if i made it clear but i am the developer of a web application,, that needs to make use of some ejb's hosted by a seperate group.
so what i am looking to do, for the users of my web application, is minimise the time it takes for them to invoke a method on one of the ejb's.
if i was to employ no pre-loading strategy. the first time the client attempts to retrieve some data from an ejb, it must connect to the ejb app server (10 seconds), using the context returned, lookup the ejb home object (4 seconds), befroe finally retrieivng a stub to the ejb and calling the method it is interested in.
at the moment i pre-connect to the ejb appserver, using a ejbfactroy object that runs at web app startup.
becasue the context is held within the ejbfactroy, when a user of the web app wants to make use of an ejb, it can skip the connection operartion and just use the pre-laoded context to create an ejb home object.
what i was wondering is if the ejb home object can also be shared by all clients? i think that it can as the ejb home object is bascally an rmi server object. in rmi there is one instance bound to the rmi registry, which is basically wha tthe ejb home is beneath the scenes.
what do you think ?
Kyle Brown
author
Ranch Hand

Joined: Aug 10, 2001
Posts: 3892
    
    5
Dean,
Most application server vendors already implement a caching strategy within their JNDI service. For example in WebSphere, we only retrieve a Home from the remote JNDI service the first time it is asked for within a client JVM -- after that it is cached, and succeeding lookups are nearly instantaneous.
Out of curiosity, which App server are you using?
Kyle


Kyle Brown, Author of Persistence in the Enterprise and Enterprise Java Programming with IBM Websphere, 2nd Edition
See my homepage at http://www.kyle-brown.com/ for other WebSphere information.
dean tomlinson
Ranch Hand

Joined: Jan 31, 2002
Posts: 94
the ejb's are hosted on a weblogic server, and my web application runs on websphere.
i feel like i have missed something fundamental. i had never even considered that i could configure my websphere app server to do any caching as the ejb's we're actually hosted by someone totally independant.
i suppose i do a similar thing for the database connections i use. these are set up with a jndi alias - and websphere handles the connection pooling.
thanks very much for your help - once again java ranch's users prove invaluable. cheers, dean
but basically what you are saying is that the home objects can be cached - eitehr by websphere or bespoke means. i think i will stick with my custom factroy, becasue i have a method called getInitialisedProductHome that takes the session and the parameters needed to set the beans primary key. inside the method it has a look if the bean is in the http session, if it is it attempts to reset it's primary key. if this doesn't throw a remote exception that instance is re-used, producing maximum re-use.
if the attempt to reset the beans primary key throws a remote exception becasue the bean had been deleted on the server, i just create a new bean instance from the home object. therefroe all the code related to the pre-laoding and caching of the ejb resources is done within my ejbfactroy.
can you see any drawbacks here - incase i'm getting tunnel vision
Phil Sharp
Ranch Hand

Joined: Nov 08, 2001
Posts: 40
Dean
Looks like you are implementing the Service Locator J2EE pattern. You might want to look up the following reference:
http://developer.java.sun.com/developer/restricted/patterns/ServiceLocator.html
Its in the restricted area so if the above does not work try
http://developer.java.sun.com/developer/technicalArticles/J2EE/patterns/Terminology.html
then go to the Service Locator link.
Its also in the Core J2EE patterns book. Unfortunately it only mentions caching as a posibility at the end with no details on best approaches.
One thought if you continue using your bespoke method you will need to catch exceptions for any home timeouts\failures that may occur at the Weblogic side. Although shouldn't be too difficult to handle.
Phil
[ May 03, 2002: Message edited by: Phil Sharp ]
Caroline Iux
Ranch Hand

Joined: May 14, 2001
Posts: 103
Originally posted by dean tomlinson:
the ejb's are hosted on a weblogic server, and my web application runs on websphere.
i feel like i have missed something fundamental. i had never even considered that i could configure my websphere app server to do any caching as the ejb's we're actually hosted by someone totally independant.

If EJBs are hosted on weblogic server, then the caching mechanism should be provided by weblogic. What Kyle was saying is many servers provide caching internally, but with differnt implementaions. One application server could have a pool of home instances ready to serve requests while another application server could have something different.
 
Consider Paul's rocket mass heater.
 
subject: EJB Resource Pooling in Client Application