This week's book giveaway is in the OCPJP forum. We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line! See this thread for details.
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
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 ]
Joined: Jan 31, 2002
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 ?
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
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
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.