EJB programming & troubleshooting: Statefull session bean, session look-up
- Posted by: Amir Jamak
- Posted on: March 27 2006 04:50 EST
I am a j2ee newbie, and this is my first post. I have a feeling that I am asking a trivial question. I have downloaded all of the free books from this site, and they are very usefull. However I couldn't find solution to my problem. Could anyone please point me some documentation or tutorial that solves the following problem.
I am trying to code j2ee application that communicates with an external servlet (protocol converter) and changes 4-5 text messages per session synchronously over http. Because the external application is not the final client, I can't use any cookie on it or any other http session mechanism. Therefore I used a statefull session bean to keep the conversation/session data: a few string variables that are changed during this session and of course the final client's ID. Untill here everything works OK.
Because the time interval between two messages is a few minutes, there is a possibility that new clients will initiate sessions in the meantime. The clients that continue sessions should reach the data from their statefull session beans. So there must be some sort of session bean look-up-by-client-ID method. Is there any standard way to implement these look-up methods like in entity beans, or I have to code it myself? Should I use entity beans instead? Any help is welcome.
In my oppinion this is something that should be found in those "hello world" examples :-), and I am kinda shamed to ask a trivial thing like this. Anyway, thanks in advance.
I'll start by explaining how stateful session beans work, as it's generally not what people expect when they first hear the designation. I'll do so by comparing to stateless beans. Here is what you have to know:
- in order to use either type of entity beans, you must obtain a handle to it from jndi (look it up).
- with, stateless session beans, using the same handle (the object that you obtain by calling create on the home that you downloaded from jndi), subsequent calls to methods defined by the remote interface can land on different instances of the implementation class. Subsequent calls may even land on different machines if you have configured some kind of a cluster.
- with stateful session beans, a session is created when you call the create method on the bean's home. The difference with stateless session beans is that it is guaranteed that calls made to remote interface methods using the same handle will go to exactly the same instance of the implementation class. If you loose your handle, you loose your session. There is no way to look-up a previous session from the jndi. if you get a new handle and you call a remote method on it, it'll start a new session.
This is why the fact that you cannot use http sessions in your servlet is kinda blocking. Normally each time a new session is started, you'd look-up your stateful and store the handle in the http session.
One way to work around your problem would be to use simulate a session using a singleton map. use the client id as key, and the stafull handle as value. This however may not work on some j2ee containers which do funny things with class loaders and as a result you can end up with multiple instances of your singleton :-) It would definitely not work in clusters.
u sure you cannot use your http session?
Emil ( http://thekirschners.com/software/testare/testare.html )
Thank you for your reply Emil,
The facts you counted above really gets to the point of this problem.
Its been a week since I posted the previous post, therefore I had to do something in the meantime :-) First, I decided to try it with entity beans and I have designed a relational database already. I feel like I am hitting a fly with a cannon, cause I need just a few string variables to be stored for a short time.
I am still looking for more elegant solution. Is it possible for example to use entity beans without connection to database? Any other ideas?
And no, unfortunatelly there is no way I can use http session, cause the final client is not browser at all, and the http client between is just a servlet doing the protocol conversion (http-smpp), and doesn't accept cookies nor can do any string rewritting...
Just a thought as I may soon be faced with a similar problem. Could you not just modify the URL you are using to access the servlet with the session data manually? Like, encode it with the proper session data, and keep track of the session id's on the client side?