• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Remote Interfaces....when using Websphere...

 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hoping someone out there can provide me with some helpful hints.... =)
I'm writing a multithreaded Java program that needs to make many calls to a stateless session bean, which resides on a remote Websphere Appserver.
At first, I wrote the program so that it'll create a new instance of the remote interface each time I needed to make a call. My program worked fine, but I noticed that WAS was eating memory like crazy since I was creating a new remote interfaces several times a second....(guess WAS wasn't garbage collecting fast enough).
Anyways, so I decided that I should only create one remote interface for each thread that I have, and reuse it instead of creating new ones. Unfortunately, WAS threw a lot of threading/pooling exceptions.
The remote interfaces that I created for each thread resided in a hashtable, which is keyed by each thread's id. When I debugged and printed out each of the remote interface's hashcode however, I noticed they were all the same. Is this normal?
At home, I did a similar experiment with JBoss, but I noticed that when creating several of the same remote interfaces, I get different hashcodes for each.
Has anyone come across similar behavior?
-Chung
 
sharp shooter, and author
Posts: 1913
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Not something that I've come across - anybody else seen this before?
Have you looked at the Service Locator pattern as a way of reusing remote objects/reducing the number of remote lookups?
Simon
[ August 02, 2002: Message edited by: Simon Brown ]
 
Ranch Hand
Posts: 401
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I could see that it might be possible if you used the same InitialContext to lookup the Home, or used the same Home to create the remotes for each thread, you might get the same instance of the stub. Implementation could have some caching going on. But I'm just speculating - I don't know.
But I'm not sure it really matters. The Remote interface stub for a Stateless session is just going to proxy to the app server, which will then pick a "random instance" from the pool for that method call.
Stateful Sessions and Entity beans are another matter, of course.
 
reply
    Bookmark Topic Watch Topic
  • New Topic