But should I be concerned about how this design will behave in a clustered environment (Websphere) .Like if the subsequent client request goes to some other server.
and the problem with storing the EJB handle in a HTTPSession instance is that if your client opens two browsers (same session) and calls 2 servlets that uses this handle to remotely call the bean, does the container takes care of this condition ?
The problem with storing the EJB handle in a HTTPSession instance is that if your client opens two browsers (same session) and calls 2 servlets that uses this handle to remotely call the bean, does the container takes care of this condition ?
Non-reentrant Instances
The container must ensure that only one thread can be executing an instance at any time. If a client
request arrives for an instance while the instance is executing another request, the container may throw
the java.rmi.RemoteException to the second request if the client is a remote client, or the
javax.ejb.EJBException if the client is a local client.[9]
Note that a session object is intended to support only a single client. Therefore, it would be an
application error if two clients attempted to invoke the same session object.
One implication of this rule is that an application cannot make loopback calls to a session bean instance.
apigee, a better way to API!
Originally posted by vish pat:
If I store the remote handle and the client id hasp map in the stateless bean then if the container destroys the stateless bean . I will loose the hashmap .
Is there any other proven mechanism to store the hashmap (other then DB ) so that i can get the reference to the stateful bean for a particular client id ?
apigee, a better way to API!
Originally posted by vish pat:
If I rely on storing the remote handle in httpsession . non java clients and webservices access will not be possible .
I am thinking of storing the clientid and remotehandle hashmap in JNDI . What do ya think ?
apigee, a better way to API!
The client id is a unique key for each transaction
No ...we derive it on the server side and pass back to client
This might be a possiblity ..but there will be only one SFSB for one transaction so multiple clients can access the bean ... I think the container should take care of the sequence/sync .?
Are you saying that no matter when a particular client makes a request to your application, the application should return the same SFSB handle?
I didnt get the question .
How can you established session for webservices ..generally that async communication .
apigee, a better way to API!