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

Remote Interfaces....when using Websphere...  RSS feed

 
Chung Chan
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • 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
 
Simon Brown
sharp shooter, and author
Ranch Hand
Posts: 1913
6
  • Mark post as helpful
  • send pies
  • 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 ]
 
Dave Landers
Ranch Hand
Posts: 401
  • Mark post as helpful
  • send pies
  • 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.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!