File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes EJB and other Java EE Technologies and the fly likes Stateless Bean Calling Stateful Bean Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Stateless Bean Calling Stateful Bean" Watch "Stateless Bean Calling Stateful Bean" New topic
Author

Stateless Bean Calling Stateful Bean

Vipul
Ranch Hand

Joined: Apr 27, 2005
Posts: 38
I have a req to call a stateful bean from a stateless bean . I have to write a mechanism to get the stateful bean from a stateless bean for a particular client

C1--> ---->SFSB1
SLSB
C2--> ---->SFSB2

Please advice

Thanks
Nitesh Kant
Bartender

Joined: Feb 25, 2007
Posts: 1638

I can not understand what is so special about calling a stateful bean from a stateless one. Isnt it the same as calling a stateful bean from any other stand alone java program?


apigee, a better way to API!
Vipul
Ranch Hand

Joined: Apr 27, 2005
Posts: 38
I have to tie the web client to the stateful bean thru a Stateless Session bean .

Each web request will create a Stateful bean using a stateless session bean So I have to Maintain or store what stateful bean is associated with the particular web request/client.

I hope I ma clear ...let me know

Web Client 01 -----> Stateless Bean ---> Stateful Bean 01
Web Client 02 -----> Stateless Bean ---> Stateful Bean 02
vu lee
Ranch Hand

Joined: Apr 19, 2005
Posts: 189
Assume your web app container and EJB container are not running on the same JVM , you can store the SFSB handler in the HttpSession, pass this handler to SLSB so that SLSB can get a reference to the SFSB. If they are running on the same JVM, store the local reference of SFSB to the HttpSession.

Why would you want to maintain two sessions (Http session and SFSB)? Could you store the state in Http session and use just SLSB?
Vipul
Ranch Hand

Joined: Apr 27, 2005
Posts: 38
Yeah , Thats what I have already mentioned in the current design .


By SFSB handler I assumed you mean a handle to the remote interface


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 ?


Thanks for all the replies !!

[ March 26, 2007: Message edited by: vish pat ]
[ March 26, 2007: Message edited by: vish pat ]
vu lee
Ranch Hand

Joined: Apr 19, 2005
Posts: 189
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 ?


1. In a cluster environment, state should be replicated on the fly, so a subsequent request could be processed by different node -- usually the secondary node since it would be better not to replicate state to all the nodes.

2. This is the same as having a SFSB with two remote stubs. If the SFSB is synchronously replicated among all nodes, then I think it should be fine. In Weblogic, the remote stub contains information which routes the request to the node containing SFSB. If this node happened to fail, it would route the request to a secondary node.
Nitesh Kant
Bartender

Joined: Feb 25, 2007
Posts: 1638

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 ?


No the container will not take care of this scenario. Session beans are not designed to be used concurrently by two different clients. Quoting from section 7.12.10 of EJB specs 2.1

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.


Now, if you want to use the same SFSB for different invocations from the same client, then you have to make sure that the code that uses this SFSB is synchronized, but, then as you pointed out, one can not really make sure of this in the clustered environment. I think you can do away with this in case there is a sticky load balancing in the clustered environment but i am not really sure. (I am not a clustering guy )
I hope i have given some clue as to what should be done :roll:

Also, i am not really sure as to how a SLSB is useful in this case. If there is no other job it does but for creating the handle of SFSB. You can not store this handle in the SLSB anyways.
[ March 27, 2007: Message edited by: Nitesh Kant ]
Vipul
Ranch Hand

Joined: Apr 27, 2005
Posts: 38
Currently I am planning to pass the remote handle to the web client itself and store it in a httpsession...but we have a requirement that a non java client should also be able to access the SFSB .I cannot pass the remote handle to a non java client .

If i store the remote handle in a SLSB on java side in a hasp map with a unique clientid as key . I run into clustering issues .

Thanks
Vishal
[ March 30, 2007: Message edited by: vish pat ]
Vipul
Ranch Hand

Joined: Apr 27, 2005
Posts: 38
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 ?
Nitesh Kant
Bartender

Joined: Feb 25, 2007
Posts: 1638

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 ?

Thou shall not store any state in a stateless bean.
I think you should go with storing the SFSB handle in the HTTPSession and live with the possibility of two clients simultaneously accessing the same SFSB handle. In the worst case, you can synchronize the call to SFSB handle with the clustering case being an exception. Thats the best solution i can think with the design that you have.
Vipul
Ranch Hand

Joined: Apr 27, 2005
Posts: 38
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 ?
Nitesh Kant
Bartender

Joined: Feb 25, 2007
Posts: 1638

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 ?


How do you get a client id? Does the client send it? If so, then is it encrypted? If not, then it can be a security problem.
What if two users send the same client id simultaneously?
How do the non-java users access your application?
Are you saying that no matter when a particular client makes a request to your application, the application should return the same SFSB handler? That means that there is no notion of a session?
If there is a notion of a session, then its not a good idea to put it on a JNDI tree. You must establish the notion of a session per client(java or non-java)
Vipul
Ranch Hand

Joined: Apr 27, 2005
Posts: 38
How do you get a client id?

The client id is a unique key for each transaction

Does the client send it?
If so, then is it encrypted? If not, then it can be a security problem.
No ...we derive it on the server side and pass back to client



What if two users send the same client id simultaneously?

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 .?


How do the non-java users access your application?
Webservices , WAP. etc ...(XML)

Are you saying that no matter when a particular client makes a request to your application, the application should return the same SFSB handler?

I didnt get the question .



That means that there is no notion of a session?
If there is a notion of a session, then its not a good idea to put it on a JNDI tree. You must establish the notion of a session per client(java or non-java)

How can you established session for webservices ..generally that async communication .
Nitesh Kant
Bartender

Joined: Feb 25, 2007
Posts: 1638


The client id is a unique key for each transaction

Each transaction means, each client request OR a transaction spans across multiple requests from the same client?

No ...we derive it on the server side and pass back to client

What does the client do with the key? Does it sends the same key back with every subsequent request?

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 .?

Yeah if every client uses a different SFSB handle, then it will not be a problem. But yeah, if the same client sends two concurrent requests(pretty much possible in a webservice scenario) then it might be an issue.


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 .

What i meant was that a SFSB handle is tied to a particular client for the lifetime of the client or it is per session. eg: When Tom makes a request to the system. A SFSB handle is initialized and assigned to him. Now, whenever, the system identifies that the user is Tom, it will use the same SFSB handle OR After a configured interval of time, this association will expire and for any subsequent requests, a new association will be created. This is on the lines of the HTTPSession paradigm.


How can you established session for webservices ..generally that async communication .

Whenever, a user logs into your system, you create a token and return it to the client. Now,in all subsequent requests, the client should send the same token back to you(WSSE binary token profile). This will help the system identify the user and establish a state across webservice requests.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Stateless Bean Calling Stateful Bean
 
Similar Threads
Seting instance pool limit for stateful session bean
Stateful session Bean
calling staeful session bean URGENT PLEASE
change stateless to stateful session bean
Dependency injection and stateful session beans