Hi, (I'm not a guru, so don't flame me please), I can give answers to items 1 & 2 I developed an a graphical client in swing made of different panels managing a lot of different data. I store the context and the different homes in public static variables so all the panels can access them. Each panel plays as a *diffrent* client if I undestand your request. All is working fine. For the item 3, I think that a proxy client pattern should make the deal... I don't remember where I got it but I can search it if needed. A++ Philippe [EMAIL PROTECTED]%internet le 19/02/2001 10:14:46 Veuillez répondre à [EMAIL PROTECTED]%internet@WTFR Pour : [EMAIL PROTECTED]%internet@WTFR cc : Objet : [jBoss-User] client side caching of Home / Remote interfaces and other perfor mance improvement questions Precedence: Bulk List-Software: LetterRip Pro 3.0.7 by Fog City Software, Inc. List-Subscribe: <mailto:[EMAIL PROTECTED]> List-Digest: <mailto:[EMAIL PROTECTED]> List-Unsubscribe: <mailto:[EMAIL PROTECTED]> Hi, We are currently developing a prototype using JBoss2.0-Final (hangs together quite nicely so far - well done guys). We have 10 beans working ok and are now evaluating performance. We run the client (servlets/resin) in separate VMs in order to be able to cluster both client (and later on hopefully the server). We are following the common pattern of using session beans as facades to entity beans in order to reduce the number of network calls. On the client side we are essentially down to the following code pattern - get the context - get home interface of the facade session bean - call create to get a bean - invoke method, get data back, compose the html page The times measure for each of the calls are around - 100ms to get the context - 80ms to get home - 100ms to call create - 80ms to invoke a method These times are more or less overhead only. Actual time spend in the method is on top. We would like to speed the client turn around up and have a few questions about what can be cached - we implemented some caching but only tested it single user so far. 1) Getting the context once, storing it in a singleton and keep using it seems to work well. Any downside doing this? 2) Getting home once and storing it and reusing it also seems to work fine. Will this work with multiple clients? Ie, is the home object always the same or does it depend on the client? 3) Caching the actual remote object for entity and statefull session beans will obviously not work, question is with stateless session beans. AFAIK, the server can create multiple instances to increase performance, but are they created on invocation of "create" (in which case they should not be cached) or are the invocation of methods dispatched to different instances (in which case we should be able to cache the remote object and use across different clients). Another performance question. In order to keep beans independend, all our entity beans are packaged into separate deployment units. Relationships between entities are implemented using separate beans which use client style lookups to get to the beans. Is there are performance penalty doing this? Should we for deployment stick all beans in one deployment unit. Any comments anyone? Any other tips and tricks to improve performance? Thanks for you help, Cheers, Robert. -- Robert Schulz [EMAIL PROTECTED] -- -------------------------------------------------------------- To subscribe: [EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] List Help?: [EMAIL PROTECTED] -- -------------------------------------------------------------- To subscribe: [EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] List Help?: [EMAIL PROTECTED]
