Conversational web services - stateful session bean in WLS9/10?

hello,
are conv web services compiled into stateful sb still?
thanks,
B.

so the conv state is in a http session, that will be replicated when running in a cluster?
thanks for this helpful information,
B.

Similar Messages

Creating web services from session beans

Hi everybody,
I want to know how to generate web services using session beans in Weblogic Worshop.
I need this urgently!!!
Any help will be very much appreciated.
Can anybody please help me......
Thanks,
Neelima

Hello,
Have you tried the tutorial?
http://e-docs.bea.com/workshop/docs81/doc/en/wls/tutorial/ejbtutorial.html
For urgent help, please make use of our excellent support team:
http://support.bea.com
Thanks,
Bruce
Neelima wrote:
>
Hi everybody,
I want to know how to generate web services using session beans in Weblogic Worshop.
I need this urgently!!!
Any help will be very much appreciated.
Can anybody please help me......
Thanks,
Neelima

Calling a web service from Session bean

Hi Experts,
Can anybody help in calling a web serivce frm a session bean's business method??
Hw do we do that?
I have one requirement where i want to send emails to set of users for which i have email sending web service ready.. How can i call it thru a session bean's business method???
Pls help,
Regards,
Amey

Hi Amey,
This documents explains how to use an EJB as Web service endpoint: http://help.sap.com/saphelp_nwce10/helpdata/en/46/307a6c50094f09e10000000a114a6b/frameset.htm
I hope this helps.
Best regards,
Ekaterina

WebLogic 10.3.0, web-service enabled session beans, and CMT transactions

Does WebLogic 10.3 support CMT for JAX-WS Web-Service enabled EJB 3.0 session beans?
When a client invokes the following Web service:
@WebService
@Stateless
@TransactionManagement( TransactionManagementType.CONTAINER )
public class TestService
    @WebMethod
    @TransactionAttribute(TransactionAttributeType.REQUIRED)
    public String echo( @WebParam( name = "param" ) final String param)
        Context context = new InitialContext();
        TransactionSynchronizationRegisttry registry =
          (TransactionSynchronizationRegistry)
            context.lookup( "java:comp/TransactionSynchronizationRegistry" );
        registry.putResource("foo", "bar");
        return param;
}WebLogic throws this exception:
SEVERE: Transaction does not exist
java.lang.IllegalStateException: Transaction does not exist
     at weblogic.transaction.internal.TransactionManagerImpl.putResource(TransactionManagerImpl.java:2033)
     at weblogic.transaction.internal.TransactionManagerImpl.putResource(TransactionManagerImpl.java:2029)Is this a bug in WL 10.3.0?
Thanks in advance.
Edited by: user572625 on Aug 18, 2011 12:29 AM

This is fixed now. Someone had defined a Servlet for the web service in web.xml that was preventing the EJB container to kick in.
Edited by: user572625 on Aug 25, 2011 11:54 PM

Problem invoking gogle web service from session bean

Hello
I have developed a Web-Client which consumes the google-WebService with Apache Axis. I have generated the corresponding classes with WSDL2Java and the client works without problems. A little code fragment from my client:
GoogleSearchService service = new GoogleSearchServiceLocator();
          // Now use the service to get a stub to the Service Definition Interface (SDI)
          GoogleSearchPort google = service.getGoogleSearchPort();
         GoogleSearchResult googleSearchResult = google.doGoogleSearch(GOOGLE_KEY, // java.lang.String key
                       q.toString(), //java.lang.String q
                       0, // int start
                       10, // int maxResults
                       false, //boolean filter
                       "", // java.lang.String restrict
                       false, //boolean safeSearch
                       "lang_ja|lang_en", // java.lang.String lr
                       "UTF-8", // java.lang.String ie
                       "UTF-8"); // java.lang.String oeNow I have to put the Web-Client in a SessionBean. Therfore I defined the code of the web-client in a method and put it into a stateless session bean and wrote a client for the session bean. But when the session bean invokes the corresponding method for consuming the google web service, there always occurs the following error:
[java] Exception in thread "main" java.rmi.ServerError: Unexpected Error; nested exception is:
[java] java.lang.NoClassDefFoundError: GoogleSearch/GoogleSearchService
But I have definitely all necessary classes in my classpath, like GoogleSearchService, etc. So all necessary classes are available. And the code to conume the web service als works because as said I tested it with a web-client.
Has anybody an idea what went wrong here? Is there anything important when I a web service is invoked by a session bean??:(
regards
pat

Has nobdy an idea?? :(( I tried for such a long time but I was not able to fix this problem....:(
Please help...

Generating web service from session bean

Hi
I have a session bean in one project which has a service-endpoint defined.
My web services are in another project entirely, within the same workspace if that helps any.
When I generate the web service from the EJB JDev turns the business tier project into a web project,
I don't see any options to include the web service in the web project.
I've reversed all of the changes, but wonder if I shouldn't redo it and copy the mapping file and configuration
across to the web project and reverse the changes in the business tier.
This is a workaround that I'm hoping to avoid, as I'm doing the "howto" for this in our project.
How is this normally done?

I tried generating the web servioce from WSDL, in the web project.
I tested and the web service works fine.
Then I changed the config file to point to the ejb, but the server won't start up....
*08/09/17 10:58:40 WARNING: Application.setConfig Application: current-workspace-app is in failed state as initialization failed.*
This is the webservices.xml bit I updated...
<ejb-link>SomeOrOtherEjbName</ejb-link> The bit I found in webservices.xml when the service is in the business tier.
 The service that works in the web tier.

Running web service in session bean or Java class

Hi All ,
I have wsdl file published on server which i can access from WebService Navigator. I have created this file using create web service option by right clicking on session bean. I want to execute this webservice in other session bean which is in other Track. How can i achieve this?
Thanks in advance
Regards
Ravi Shankar

Hi Ravi,
1ce the service is published ..you can execute the service by making the instance out of it or the other option is you can use jaxrpc or saajapi for dealing with SOAP api directly

How to use WS-RM web Service from Session Bean?

Hi all.
Could you tell me the way how to call WS-RM web service(Staring BPM Process) from SessionBean?
Our environment: SAP NetWeaver CE 7.2 SP3
I do the following.
I have created a BPM Process starting with Message Start Event.
This Message Start Event was created by Service Interface(stateless and asynchronous) which was imported from ESR.
I deployed this into my server and it worked fine in webservice navigator as a WS-RM WebService.
But I can't call this webservice from SessionBean in EJBExplorer.
I get the following error message:
Caused by: This exception is wrapper of javax.xml.ws.soap.SOAPFaultException. com.sap.engine.services.webservices.espba
se.client.bindings.exceptions.SOAPFaultException: Invalid WS-RM message. There are no WS-RM headers within SOAP message.
at com.sap.engine.services.webservices.espbase.client.bindings.impl.JAXWSUtil.processFault(JAXWSUtil.java:412)
at com.sap.engine.services.webservices.espbase.client.bindings.impl.SOAPTransportBinding.call_SOAP(SOAPTransportBinding.java:1366)
at com.sap.engine.services.webservices.espbase.client.bindings.impl.SOAPTransportBinding.callWOLogging(SOAPTransportBinding.java:960)
at com.sap.engine.services.webservices.espbase.client.bindings.impl.SOAPTransportBinding.call(SOAPTransportBinding.java:915)
at com.sap.engine.services.webservices.espbase.client.jaxws.core.WSInvocationHandler.processTransportBindingCall(WSInvocationHandler.java:168)
at com.sap.engine.services.webservices.espbase.client.jaxws.core.WSInvocationHandler.invokeSEISyncMethod(WSInvocationHandler.java:121)
at com.sap.engine.services.webservices.espbase.client.jaxws.core.WSInvocationHandler.invokeSEIMethod(WSInvocationHandler.java:84)
at com.sap.engine.services.webservices.espbase.client.jaxws.core.WSInvocationHandler.invoke(WSInvocationHandler.java:65)
at $Proxy2753.zwsvCheckOrderdataMainprocessStart(Unknown Source)
at jp.co.ogis_ri.WSTestSessionBean.exeWS(WSTestSessionBean.java:81)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
I created this SessionBean as follows:
I created DCs for EJB and created SessionBean in EJB DC.
I imported a WSDL file(WS-RM web service) from Service Registory and
I created service clients and Service References.
After that I implemented SessionBean to call web service checking with this help.
http://help.sap.com/saphelp_nwce72/helpdata/en/44/4d2bb1c6b00597e10000000a155369/frameset.htm
After deploying this EJB,I configured properties in nwa.
Thanks
Yuichi

Yuichi
Did you manage to solve this? I'm doing something similar and seeing the same problem, although they're up to 7.3 SP7.
Any help greatly appreciated.
Lewis

Pass form data through web service to session bean

Hello,
i want to create an insert in a database table using a web dynpros that call my method createEntry i a sessionbean. The sessionbean is ok, it worked with a jsp.
My Problem:
The inputfields of my form are blocked so that i cannot insert the values. This problem only occurs if i bind the inputfields to the attributes of my web service in the view context.
What i already did:
I defined a web service in my EJB Module Project.
I imported this model into my web dynpro.
I bound the elements of the web service into the custom controller.
I bound the elements from the custom controller to my view context.
I did not bind the result of the web service in any way because i do not need it.
Did i miss something i had to do?
Thanks for help or any advices, it is my first time using a web service and i already tried to get along with the CarRental and the Email example.
André

Hi,
I think you problem is not a Web Service but the fact that Model Context Elements are not created automatically.
>I bound the elements of the web service into the custom >controller.
You made a binding but here you should <b>create</b> the elemnts itself wich means:
1. Create the instance of the element for you cotext node.
2. Call wdContext.node<You Context Name>.bind(<instance created in previous step>
This step is the same as for RFC Model so if you fill that my explanation is not clear enought go to Adptive RFC Model tutorial (calling BAPI_FLIGHT_GET_LIST) and see the code in wdDoInit() method.
Hope it helps.
Victor

Web Service from stateful Session Bean deleted after server restart

Hi,
i created a stateful session bean and from this a web service.
I am able to deploy it and it works really fine.
My problem is: after a server restart the web service is gone and i
have to deploy it again.
I have some other web services (but these are web services from stateless session beans)
but they "survive" the server restart.
I don't want to deploy the web service after every server restart, did I forget something or
is it a general problem of stateful session beans or web services?
Thanks in advance
Jens

Hello Björn,
I am not quite sure what your problem is but did you have a look at these articles:
http://help.sap.com/saphelp_nw04/helpdata/en/4d/993441c73cef23e10000000a155106/frameset.htm
http://help.sap.com/saphelp_nw04/helpdata/en/be/2e2c4142aef623e10000000a155106/frameset.htm
I hope they can give you some idea.
Regads
Vyara

Context.lookup in a Servlet always returns the same Stateful Session Bean

Hi,
I am working on an application in which a Servlet should obtain one StateFul Session Bean per client. I read in EJB 3.0 in Action that to do so I should use a jndi lookup and save the result of the lookup in an HttpSession. This works fine for me when I have a single client.
My issue is that when I have several clients, context.lookup returns the same SFSB for each client. This means that I end up having a single SFSB for the whole application. I've been browsing the web for a while now trying to find a solution but haven't had any luck yet.
The code I use to obtain and save the SFSB is the following:
HttpSession session = request.getSession(true);
DFMServiceRemote service = (DFMServiceRemote) session.getAttribute("DFMService");
if (null == service)
service = (DFMServiceRemote) new InitialContext().lookup("DFMService");
session.setAttribute("DFMService", service);
}Using different browser, I end up with different HttpSession but a single SFSB. The only workaround I found is to create the context with environment variables or properties. It then returns different SFSBs for different HttpSession. The workaround code is as below:
Hashtable<String, String> env = new Hashtable<String, String>();
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.evermind.server.rmi.RMIInitialContextFactory");
env.put(Context.SECURITY_PRINCIPAL, "oc4jadmin");
env.put(Context.SECURITY_CREDENTIALS, "welcome");
env.put(Context.PROVIDER_URL, "ormi://localhost:23791/DriverFatigue");
service = (DFMServiceRemote) new InitialContext(env).lookup("DFMService");My question is the following. How can I get a different instance of an SFSB every time I execute context.lookup without specifying properties.
Thanks in advance for any help,
Matthieu Siggen

I just did something similar in another project using JBoss instead of oc4j and didn't have any problem. I expect I missed a configuration file in oc4j or there is a conflict somewhere.

Stateful Session Beans are not passivated / serialized when cache idle time

Technology: Sun Application Server version 7.0.0_01; JDK 1.4.1; developed on Windows 2000; Tested on Sun Solaris.
Initial error on Sun Solaris:
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: Exception in thread "service-j2ee-25" org.omg.CORBA.OBJ_ADAPTER: vmcid: SUN minor code: 1015 completed: No
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.POA.GenericPOAServerSC.preinvoke(GenericPOAServerSC.java:389)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.POA.ServantCachePOAClientSC.initServant(ServantCachePOAClientSC.java:112)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.POA.ServantCachePOAClientSC.setOrb(ServantCachePOAClientSC.java:95)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.iiop.CDRInputStream_1_0.createDelegate(CDRInputStream_1_0.java:760)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.iiop.CDRInputStream_1_0.internalIORToObject(CDRInputStream_1_0.java:750)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.iiop.CDRInputStream_1_0.read_Object(CDRInputStream_1_0.java:669)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.iiop.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:890)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.iiop.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:884)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.iiop.CDRInputStream.read_abstract_interface(CDRInputStream.java:307)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.se.internal.io.IIOPInputStream.readObjectDelegate(IIOPInputStream.java:228)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.se.internal.io.IIOPInputStream.readObjectOverride(IIOPInputStream.java:381)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at java.io.ObjectInputStream.readObject(ObjectInputStream.java:318)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.enterprise.iiop.IIOPHandleDelegate.getStub(IIOPHandleDelegate.java:58)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.enterprise.iiop.IIOPHandleDelegate.readEJBObject(IIOPHandleDelegate.java:38)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.ejb.portable.HandleImpl.readObject(HandleImpl.java:91)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.se.internal.io.IIOPInputStream.readObject(Native Method)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.se.internal.io.IIOPInputStream.invokeObjectReader(IIOPInputStream.java:1298)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.se.internal.io.IIOPInputStream.inputObject(IIOPInputStream.java:908)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.se.internal.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:261)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.se.internal.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:247)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.se.internal.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:209)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.iiop.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:981)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.iiop.CDRInputStream.read_value(CDRInputStream.java:287)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.javax.rmi.CORBA.Util.copyObject(Util.java:598)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at javax.rmi.CORBA.Util.copyObject(Util.java:314)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.telstra.nodeman.ejb._NodeMaint_Stub.getHandle(Unknown Source)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.telstra.nodeman.arch.NMAViewBeanProxy.checkBeans(NMAViewBeanProxy.java:631)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.telstra.nodeman.view.html.NMAStandardButton.handleRequest(NMAStandardButton.java:143)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.telstra.nodeman.arch.NMAViewBeanBase.handleRequest(NMAViewBeanBase.java:1573)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.iplanet.jato.view.ViewBeanBase.dispatchInvocation(ViewBeanBase.java:824)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.iplanet.jato.view.ViewBeanBase.invokeRequestHandlerInternal(ViewBeanBase.java:637)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.iplanet.jato.view.ViewBeanBase.invokeRequestHandler(ViewBeanBase.java:595)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.iplanet.jato.ApplicationServletBase.dispatchRequest(ApplicationServletBase.java:772)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.iplanet.jato.ApplicationServletBase.processRequest(ApplicationServletBase.java:446)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.iplanet.jato.ApplicationServletBase.doPost(ApplicationServletBase.java:324)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.telstra.nodeman.view.ViewServlet.doPost(ViewServlet.java:243)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardWrapperValve.invokeServletService(StandardWrapperValve.java:720)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardWrapperValve.access$000(StandardWrapperValve.java:118)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardWrapperValve$1.run(StandardWrapperValve.java:278)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at java.security.AccessController.doPrivileged(Native Method)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:274)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:505)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:212)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:505)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:203)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:505)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.iplanet.ias.web.connector.nsapi.NSAPIProcessor.process(NSAPIProcessor.java:158)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.iplanet.ias.web.WebContainer.service(WebContainer.java:598)
The above error caused the server to use all available memory and required a reboot to proceed.
Subsequent testing against the Sun Appliucation Server 7 on Windows 2000 dev environment using the Sun Studio IDE for debugging and trace statements inserted in the code indicate that the Application Server is removing the Stateful Session Beans when they time out without an ejbPassivate event and without serializing the beans to the data-store. cache-idle-timeout-in-seconds set to 180 and removal-timeout-in-seconds set to 1800.
The server.log indicates that the beans are timing out:
[19/Aug/2004:18:15:10] WARNING ( 1664): [NRU-com.telstra.nodeman.ejb.AddressMaintBean]: IdleBeanCleanerTask finished after removing 2 idle beans
Trace statements inserted in ejbPassivate do not appear in the log.
It is my understanding that the above timeout should have caused an ejbPasssivate and serialization of the beans.
The beans have been validated using Sun Java Studio Enterprise 6 with 'EJB validate'.
My reading of the problem is that the beans are not being serialized and the error occurs when the application attempts to reference (getHandle) the bean after timeout.
Any suggestions would be appreciated.

Thanks Thorick.
I am using NRU caching. WL 7.0 SP2.
I have not defined idle-timeout-seconds in my weblogic-ejb-jar.xml. As I understand
the default value for this is 600secs. So the ejbs should be removed after this
time. Below is the
weblogic-ejb-jar.xml that I am using.
<!DOCTYPE weblogic-ejb-jar PUBLIC '-//BEA Systems, Inc.//DTD WebLogic 7.0.0 EJB//EN'
'http://www.bea.com/servers/wls700/dtd/weblogic-ejb-jar.dtd'>

<weblogic-ejb-jar>
<weblogic-enterprise-bean>
<ejb-name>Cart</ejb-name>
<stateful-session-descriptor>
<stateful-session-clustering>
<home-is-clusterable>true</home-is-clusterable>
<replication-type>InMemory</replication-type>
</stateful-session-clustering>
</stateful-session-descriptor>
<transaction-descriptor>
     <trans-timeout-seconds>
          60
     </trans-timeout-seconds>
</transaction-descriptor>
<jndi-name>CartHome</jndi-name>
</weblogic-enterprise-bean>
</weblogic-ejb-jar>
"thorick" <[email protected]> wrote:
>
The idle-timeout-seconds property controls the timeout/removal behavior.
which stateful session cache type are you using ? LRUCache or NRUCache

What are the advantages stateful session beans takes over than HttpSession

Hi
We can use HttpSession to maintain the conversational state with the client.
Then why we need to go for stateful session beans to maintain conversational state with the client.
What are advantages we can have while using stateful session beans ratherthan HttpSession????.
Regards
Dhinesh kumar R

I think we can use the magic word in the software development "seperation of concerns" ;-)
HttpSession is in the Servlet/JSP tier and is mainly used in the presentation logic tier (UI, page flows, navigation etc..)
where the stateful session bean's concern is to maintain a conversational state in a business logic tier.
Through this seperation its possible, that the business tier's state is undependant from the HttpSession and you dont create a hardlink that could cause problems later. Imagine having a desktop client accessing your business logic etc. not every client needs to be a web client ;-)
I hope that the answer helps you understanding the topic :-)
Brgds,
Nail

Accessing the same stateful session bean from multiple clients in a clustered environment

I am trying to access the same stateful session bean from multiple
          clients. I also want this bean to have failover support so we want to
          deploy it in a cluster. The following description is how we have tried
          to solve this problem, but it does not seem to be working. Any
          insight would be greatly appreciated!
          I have set up a cluster of three servers. I deployed a stateful
          session bean with in memory replication across the cluster. A client
          obtains a reference to an instance of one of these beans to handle a
          request. Subsequent requests will have to use the same bean and could
          come from various clients. So after using the bean the first client
          stores the handle to the bean (actually the replica aware stub) to be
          used by other clients to be able to obtain the bean. When another
          client retrieves the handle gets the replica aware stub and makes a
          call to the bean the request seems to unpredictably go to any of the
          three servers rather than the primary server hosting that bean. If the
          call goes to the primary server everything seems to work fine the
          session data is available and it gets backed up on the secondary
          server. If it happens to go to the secondary server a bean that has
          the correct session data services the request but gives the error
          <Failed to update the secondary copy of a stateful session bean from
          home:ejb20-statefulSession-TraderHome>. Then any subsequent requests
          to the primary server will not reflect changes made on the secondary
          and vice versa. If the request happens to go to the third server that
          is not hosting an instance of that bean then the client receives an
          error that the bean was not available. From my understanding I thought
          the replica aware stub would know which server is the primary host for
          that bean and send the request there.
          Thanks in advance,
          Justin


          If 'allow-concurrent-call' does exactly what you need, then you don't have a problem,
          do you?
          Except of course if you switch ejb containers. Oh well.
          Mike
          "FBenvadi" <[email protected]> wrote:
          >I've got the same problem.
          >I understand from you that concurrent access to a stateful session bean
          >is
          >not allowed but there is a
          >token is weblogic-ejb-jar.xml that is called 'allow-concurrent-call'
          >that
          >does exactly what I need.
          >What you mean 'you'll get a surprise when you go to production' ?
          >I need to understand becouse I can still change the design.
          >Thanks Francesco
          >[email protected]
          >
          >"Mike Reiche" <[email protected]> wrote in message
          >news:[email protected]...
          >>
          >> Get the fix immediately from BEA and test it. It would be a shame to
          >wait
          >until
          >> December only to get a fix - that doesn't work.
          >>
          >> As for stateful session bean use - just remember that concurrent access
          >to
          >a stateful
          >> session bean is not allowed. Things will work fine until you go to
          >production
          >> and encounter some real load - then you will get a surprise.
          >>
          >> Mike
          >>
          >> [email protected] (Justin Meyer) wrote:
          >> >I just heard back from WebLogic Tech Support and they have confirmed
          >> >that this is a bug. Here is their reply:
          >> >
          >> >There is some problem in failover of stateful session beans when its
          >> >run from a java client.However, it is fixed now.
          >> >
          >> >The fix will be in SP2 which will be out by december.
          >> >
          >> >
          >> >Mike,
          >> >Thanks for your reply. I do infact believe we are correctly using
          >a
          >> >stateful session bean however it may have been misleading from my
          >> >description of the problem. We are not accessing the bean
          >> >concurrently from 2 different clients. The second client will only
          >> >come into play if the first client fails. In this case we want to
          >be
          >> >able to reacquire the handle to our stateful session bean and call
          >it
          >> >from the secondary client.
          >> >
          >> >
          >> >Justin
          >> >
          >> >"Mike Reiche" <[email protected]> wrote in message
          >news:<[email protected]>...
          >> >> You should be using an entity bean, not a stateful session bean
          >for
          >> >this application.
          >> >>
          >> >> A stateful session bean is intended to be keep state (stateful)
          >for
          >> >the duration
          >> >> of a client's session (session).
          >> >>
          >> >> It is not meant to be shared by different clients - in fact, if
          >you
          >> >attempt to
          >> >> access the same stateful session bean concurrently - it will throw
          >> >an exception.
          >> >>
          >> >> We did your little trick (storing/retrieving handle) with a stateful
          >> >session bean
          >> >> on WLS 5.1 - and it did work properly - not as you describe. Our
          >sfsb's
          >> >were not
          >> >> replicated as yours are.
          >> >>
          >> >> Mike
          >> >>
          >> >> [email protected] (Justin Meyer) wrote:
          >> >> >I am trying to access the same stateful session bean from multiple
          >> >> >clients. I also want this bean to have failover support so we want
          >> >to
          >> >> >deploy it in a cluster. The following description is how we have
          >tried
          >> >> >to solve this problem, but it does not seem to be working. Any
          >> >> >insight would be greatly appreciated!
          >> >> >
          >> >> >I have set up a cluster of three servers. I deployed a stateful
          >> >> >session bean with in memory replication across the cluster. A client
          >> >> >obtains a reference to an instance of one of these beans to handle
          >> >a
          >> >> >request. Subsequent requests will have to use the same bean and
          >could
          >> >> >come from various clients. So after using the bean the first client
          >> >> >stores the handle to the bean (actually the replica aware stub)
          >to
          >> >be
          >> >> >used by other clients to be able to obtain the bean. When another
          >> >> >client retrieves the handle gets the replica aware stub and makes
          >> >a
          >> >> >call to the bean the request seems to unpredictably go to any of
          >the
          >> >> >three servers rather than the primary server hosting that bean.
          >If
          >> >the
          >> >> >call goes to the primary server everything seems to work fine the
          >> >> >session data is available and it gets backed up on the secondary
          >> >> >server. If it happens to go to the secondary server a bean that
          >has
          >> >> >the correct session data services the request but gives the error
          >> >> ><Failed to update the secondary copy of a stateful session bean
          >from
          >> >> >home:ejb20-statefulSession-TraderHome>. Then any subsequent requests
          >> >> >to the primary server will not reflect changes made on the secondary
          >> >> >and vice versa. If the request happens to go to the third server
          >that
          >> >> >is not hosting an instance of that bean then the client receives
          >an
          >> >> >error that the bean was not available. From my understanding I
          >thought
          >> >> >the replica aware stub would know which server is the primary host
          >> >for
          >> >> >that bean and send the request there.
          >> >> >
          >> >> >Thanks in advance,
          >> >> >Justin
          >>
          >
          >

EJB 3.0 Stateful session bean shared between Servlet's

Hello
I have a bit of a noob question regarding Stateful sessions beans.
I am wanting to know if there is a way that I can share an instance of a session bean between multiple HttpServlet instances?
I am sending XML messages from a mobile J2ME application, there will be several http POST's made from the mobile client to the server. I would like these multiple POST's to be passed from the handling servlet instance to the same uniquely identified single stateful session bean instance (i can then @Remove the stateful bean when I have finished my several requests).
I would greatly appreciate any tips anyone could give me.

If not, your only option is to maintain the
association yourself by creating a unique id for
each
conversation and storing that id along with the SFSB
reference in the ServletContext. Then you'll
need to pass the id in along with each invocation to
retrieve the appropriate SFSB reference.Thanks for your reply.
Will I always be presented with the same ServletContext instance? Even if the time between requests might be many minutes? Where can I learn more about how to use the ServletContext?
Thanks!

Conversational web services - stateful session bean in WLS9/10?

Similar Messages

Maybe you are looking for