Im having a problem with stateful session beans in Iplanet running IAS6.0 with SP2 (clustered), sticky is false, application is distributed.

I get the following:
error: EB-013: Unable to create timer for home

Hi,
This exception indicates that there is some problem in creation of EJBObject or remote object. Can you please increase the debug level of iAS, and provide KJS logs and also some more information about your application. It will be best if you can send me a copy of your application, I can deploy it here and will try to see the exact cause of the exception.
You can mail your application/test case on [email protected] or post it here.
Regards,
Sanjeev.

Similar Messages

  • 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
              >>
              >
              >
              

  • Error in updating secondary stateful session bean

              Hi all,
              I have set up a cluster of 2 managed servers with WebLogic 6.1. I have a
              stateful session bean and several stateless session beans. the stateful
              session bean keeps user info and limited cached objects, all are
              serializable. it seems working fine, even after killing any one of the
              servers, as long as one is alive. a java application client creates a
              stateful session bean first, then calls stateless session beans with the
              remote interface of the stateful bean as a method parameter. No problem
              when stateful session bean is created. However, each stateless bean method
              generates the following error message if I turn the debug on (level 64). No
              exception stack traces, and all methods execute successfully.
              <Error> <EJB> <Failed to update the secondary copy of a stateful session
              bean from home:clientsession>
              I wonder what causes the error, and why it tries to update the stateful
              session bean. in all stateless session beans, only read into the stateful
              bean.
              Thank you,
              Fujin
              

    This has been fixed in WLS 6.1 SP2.
              jagdip Talla wrote:
              > Hi Fujin,
              > please let me know, if u were able to solve the problem..
              >
              > hi guys,
              > appreciate if you could give me some clues
              > how to solve this problem ?
              >
              > i hv 2 WLS instances in a cluster,
              > when one server instance is shut down, i keep getting these errors ?
              > is it normal ?
              > <Feb 19, 2002 2:57:53 PM SGT> <Error> <EJB> <Failed to update the secondary copy of a stateful session bean from home:ejb/xyzrel1_2/xxxxHome>
              >
              > appreciate if u can let me know, if u could solve it..?
              >
              > thanks n regads
              > jagdip
              Rajesh Mirchandani
              Developer Relations Engineer
              BEA Support
              

  • SAME EJB 3.0 Stateful Session bean for different JSP sessions returned

    Forum,
    I have a strange problem utilizing stateful session beans. Please note, that I am using jdeveloper for the following:
    1) Here is a basic stateful session bean:
    @Stateful(name = "DemoClass")
    public class DemoClassBean implements DemoClass,
               DemoClassLocal, SessionSynchronization {
          public static int id=0;
          public DemoClassBean() {
          id++;
          public int getId() {
             return id;
          //... other methods
    }2) This bean is accessed from a JSP for testing purpose, I am copying only the script used in JSP:
    <%
       DemoClass bean = null;
       try {
          bean = (DemoClass) ((new javax.naming.InitialContext()).
                       lookup("DemoClass "));
          System.out.println("ID=" + bean.getId() );
          } catch (javax.naming.NamingException e) {
             // TODO
    %>If this page is addressed by different clients, from different browsers, the same bean is returned.
    Here is what I see in the logs:
    ID=1
    ID=1
    ID=1
    The same problem is being observed when this session bean is accessed from a JSF Backing bean.
    What could be wrong? Is this a bug in oc4j / jdeveloper (version 10.1.3.3.0)?
    Edited by: smw000000001 on Nov 17, 2008 10:52 AM

    Hi,
    The code for stateful is perfectly fine and working in a normal way. The way you are trying to implement the stateful session bean in your application is wrong.
    think of binding the stateful session bean with HttpSession object.
    So that you will get a unique stateful session bean object.

  • Deploy Error when using Stateful Session Bean inside Webdynpro

    Hi,
    I'm trying to create a webdynpro project that uses a stateful session bean
    I have created DC's for a EJB Module project, Enterprise Application and Webdynpro component. Created the bean, built it, added it's package to the public part, added the EJB Module to the EAR project. Built the EAR project. Added the EJB Module project and Enterprise Application project as a used DC in the Webdynpro DC.
    In the Webdynpro DC I added com.sap.archive-packaging.default.update-descriptors=true in the build.properties file of the cfg directory. (using the navigator view) That resolved an error while building it.
    Deployed the Enterprise Application DC without problems.
    Tried to deploy the Webdynpro DC but I get the following error:
    Jun 16, 2008 9:40:46 AM /userOut/deploy (com.sap.ide.eclipse.sdm.threading.DeployThreadManager) [Thread[Deploy Thread,5,main]] WARNING:
    [012]Deployment finished with warning
    Settings
    SDM host : 10.64.36.74
    SDM port : 50018
    URL to deploy : file:/C:/DOCUME~1/JESCHA~1/LOCALS~1/Temp/temp59822company.nl~projempactcmp.ear
    Result
    => deployed with warning : file:/C:/DOCUME~1/JESCHA~1/LOCALS~1/Temp/temp59822company.nl~projempactcmp.ear
    Finished with warnings: development component 'projempactcmp'/'company.nl'/'local'/'20080616094022':Caught exception during application startup from SAP J2EE Engine's deploy service:java.rmi.RemoteException: Error occurred while starting application company.nl/projempactcmp and wait. Reason: Clusterwide execption: server ID 6060950:<--Localization failed: ResourceBundle='com.sap.engine.services.deploy.DeployResourceBundle', ID='com.sap.engine.services.deploy.container.DeploymentException: <--Localization failed: ResourceBundle='com.sap.engine.services.deploy.DeployResourceBundle', ID='Failed implicit start for company.nl/projempejb : Unknown state(5)', Arguments: []--> : Can't find resource for bundle java.util.PropertyResourceBundle, key Failed implicit start for company.nl/projempejb : Unknown state(5)', Arguments: []--> : Can't find resource for bundle java.util.PropertyResourceBundle, key com.sap.engine.services.deploy.container.DeploymentException: <--Localization failed: ResourceBundle='com.sap.engine.services.deploy.DeployResourceBundle', ID='Failed implicit start for company.nl/projempejb : Unknown state(5)', Arguments: []--> : Can't find resource for bundle java.util.PropertyResourceBundle, key Failed implicit start for company.nl/projempejb : Unknown state(5) (message ID: com.sap.sdm.serverext.servertype.inqmy.extern.EngineApplOnlineDeployerImpl.performAction(DeploymentActionTypes).REMEXC)
    Deployment exception : Got problems during deployment
    Does anyone know what this error means and how to resolve it. I searched the forum but only found errors that look like this relating to XI not to Webdynpro.......
    Thansk,
    Jeschael
    Edited by: J.V. Lebbink on Jun 17, 2008 6:52 AM

    Default is 30mts.
    This is done as a parameter in orion-ejb-jar.xml. Please look at the EJB Guide at http://otn.oracle.com/docs/products/ias/doc_library/903doc_otn/generic.903/a97677/dtdxml.htm#634197 for details
    regards
    Debu

  • 1) Second thread call to stateful session bean.

    Hi Friend,
    I read your threads on otn and i compared your problem with us and i analysed that your application and my application is same, So Plese can you help me in some issues.
    Friend, Please help me in these issues, Thanks for this
    We have very big ADF Swing+BC Application and deployed as Stateful Session Bean. in my application there are 500 Application Modules,For each application module i created Stateful session beans and deployed it on OC4J Container but when working on deployed application then i am getting time out error after 15 min of working.
    1). I set that parameter that you mentioned i.e jbo.ejb.txntimeout = 86400,but still it is giving me same error.
    2). Second Issue is of ---ORA-01000: maximum open cursors exceeded
    For this issue i chaged the Database Parameter i.e OpenCurser=2000, but still it is giving me same error,
    is there any parameter on application module required to change so that this error will not come.
    3). When i close the form then application module is not releasing database connection.
    4). (oracle.oc4j.rmi.OracleRemoteException) Second thread call to stateful session bean
    This error is also coming when I am using deployed application for long time i.e more than 15 min for Heavy Transactions

    Hi Suyog,
    How r u?
    We all are fine.
    I alerady tried for the Max Curser Property but it is not helpfull.
    I think again i have to go for closing opened db RS and statements.
    Thanks
    Vijay

  • 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

  • HT200169 Having a problem with Logic 9 on a Mac Pro.Working on a lenghty song and apparently session got corrupted.Doesnt let me export tracks,program crashes.Already tried start brand new session with the tracks imported into it but still wont export.Sug

    Hello,having a problem with Logic 9 on a Mac Pro.Working on a lenghty song and apparently session got corrupted.Doesnt let me export tracks,program crashes.Already tried start brand new session with the tracks imported into it but still wont export.Suggestions?

    Thanks, Ian. Yeah, that's how I do it now...or with the controls in the left side pane. Still, I would have liked that quick on-the-spot edit capability...especially while sketching.
    Ian Turner wrote:
    Sorry Mark, you are out of luck as it does not do that - it works the same as L8. The way I would achieve that with more accuracy and control would be to route all the tracks you want to fade to a Bus then use volume automation on the bus. To do this you will need to add a standard audio track, then re-assign it using (Control Click on the track header) to the Bus track. You can then automate volume/plugins etc on the Bus track.
    Ian

  • Share stateful session bean in JSF managed beans with different scope

    Hi,
    I have a JSF application and I want to try to use of stateful session beans.
    So I created a new stateful session bean and its local interface.
    @Stateful
    public class StatefulSessionBean implements StatefulSessionBeanLocalInterface{
    private String name;
    @Local
    public interface StatefulSessionBeanLocalInterface {
    ...In my JSF application I have a mananed bean with session context which registers the new interface by
    this annotation
    @EJB(name="sessionbeanref", beanInterface=StatefulSessionBeanLocalInterface.class) and set the name to something.
    Now I want to fetch this name in another managed bean with request scope. So I looked up the bean and tried to get the name.
    StatefulSessionBeanLocalInterface = (StatefulSessionBeanLocalInterface) new InitialContext().lookup("java:comp/env/sessionbeanref");
    System.out.println(currentmailingbean.getName());but the name is null.
    Why?

    The xsd was created via the netbeans J2EE enterprise application dialog and I think its the most recent.
    <?xml version="1.0" encoding="UTF-8"?>
    <web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">All other annotations seem to work.
    Wouldnt the lookup completely fail if the deployment process thought that it is version 1.4 ?

  • Stateful Session Bean with BMT: JDBCpmf or EEpmf?

    Quote:
    For the record: when using BMT as David described, you should use a JDBCPersistenceManagerFactory
    instead of an EEPersistenceManagerFactory. EEPersistenceManagerFactory is only appropriate when
    transaction synchronization is desired.
    -Patrick
    Hi Patrick,
    I wanted to follow up on this. In the case of Kodo, the JDBCpmf does not turn on the
    UserTransaction in a managed environment, while the EEpmf does. My question: isn't is necessary to
    turn on the UserTransaction in a stateful session bean with BMT? If this doesn't happen, isn't
    there a danger, if the bean allows transactions to span business method invocations, that the
    container will passivate the bean while a transaction is active? Since the PM can't be saved during
    passivation, the tx would be interrupted by passivation -- something that would not happen if the
    container were aware that a tx was active.
    David Ezzio

    David,
    My interpretation of your initial post was that you were using fully
    unmanaged transactions in your bean. That is, that you were not using the
    UserTransaction, but were just using the javax.jdo.Transaction for
    transactional data store access.
    In the situation I just described, using the EEPMF would result in changes
    to the UserTransaction. If your goal was to manage the UserTransaction in
    the bean, then yes, you'd still want to use the EEPMF.
    -Patrick
    On 7/25/02 7:17 PM, "David Ezzio" <[email protected]> wrote:
    Quote:
    For the record: when using BMT as David described, you should use a
    JDBCPersistenceManagerFactory
    instead of an EEPersistenceManagerFactory. EEPersistenceManagerFactory is only
    appropriate when
    transaction synchronization is desired.
    -Patrick
    Hi Patrick,
    I wanted to follow up on this. In the case of Kodo, the JDBCpmf does not turn
    on the
    UserTransaction in a managed environment, while the EEpmf does. My question:
    isn't is necessary to
    turn on the UserTransaction in a stateful session bean with BMT? If this
    doesn't happen, isn't
    there a danger, if the bean allows transactions to span business method
    invocations, that the
    container will passivate the bean while a transaction is active? Since the PM
    can't be saved during
    passivation, the tx would be interrupted by passivation -- something that
    would not happen if the
    container were aware that a tx was active.
    David Ezzio--
    Patrick Linskey [email protected]
    SolarMetric Inc. http://www.solarmetric.com

  • Problem using application client for local stateful session bean

    Hi,
    I have deployed a local stateful session bean in Sun J2EE 1.4 application server.
    On running the applclient for the stateful session bean application client i get the following error:
    Warning: ACC006: No application client descriptor defined for: [null]
    cant we use application client for local stateful session beans. becoz the application runs smoothly when i changed the stateful sesion bean to remote.

    Hi,
    No, an ejb that exposes a local view can only be accessed by an ejb or web component packaged within the same application. Parameters and return values for invocations through the ejb local view are passed by reference instead of by value. That can't work for an application client since it's running in a separate JVM.
    --ken                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

  • 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 Bean accesed by two JSPs.

    Hi there,
    We are having quite an issue; we have an application that stores session
    state in an stateful session bean. And we have noticed some parts of the
    application create a situation where is possible that two frames -and so two
    jsp- access the session bean at the same time. And, of course, it´s going to
    be the same instance of the session bean..... what will be the behaviour in
    this case?. Will the requests be serialized, an exception will be thrown or
    the EJB will be destroyed?. Not very sure of what would happen. I suppose
    there could be some problems with this-. I would appreciate any help.
    Many thanks. Best regards.

    Hrm. EJB spec is quite clear on what will happen (RemoteException thrown) if
    the second client attempts to use Stateful Session bean which is already in
    use (and the bean will not be destroyed - container will simply throw an
    exception after failing to acquire a lock on the bean instance without waiting
    (allow-concurrent-calls option in WebLogic allows client call to wait to acquire
    lock - this was probably added as a convinience feature for applications which
    use frames)).
    So, normally your application has to ensure that no 2 clients are able to use
    the same stateful session bean concurrently, or use allow-concurrent-calls option,
    which will do that for you, but the application will become non portable.
    Dimitri
    PS: Thanks. Maine Coon cats are the best. Ours is a 22-pound giant ;-)
    Pinklon Thomas <[email protected]> wrote:
    Hi Dimitri,
    Thnaks a lot for the help:one thing that I do not know if it´s an issue is
    that calls come from different JSPs; the strategy I have seen in another Web
    application servers is trying to activate the EJB in the middle of another
    transaction... In this situation, the container cannot activate the EJB,
    roolback the transaction and destroys the EJB.... Would Weblogic feature
    avoid this?. I will investigate on my part....
    Many many thnaks. Nice cats.
    "Dimitri Rakitine" <[email protected]> wrote in message
    news:[email protected]...
    In 6.1 you can set allow-concurrent-calls to true in this situation:
    <!--
    The allow-concurrent-calls specifies whether a stateful session bean
    instance will allow concurrent method calls. The value of this
    element may be either "True" or "False". The default value is
    "False". When a stateful session bean instance is currently in a
    method call and another (concurrent) method call arrives on the
    server, the EJB specification requires that the server throw a
    RemoteException. By default, allow-concurrent-calls is false, and the
    EJB container will follow the EJB specification. When this value is
    set to true, the EJB container will block the concurrent method call
    and allow it to proceed when the previous call has completed.
    Used in: stateful-session-descriptor
    -->
    Pinklon Thomas <[email protected]> wrote:
    Hi there,
    We are having quite an issue; we have an application that stores
    session
    state in an stateful session bean. And we have noticed some parts of the
    application create a situation where is possible that two frames -and sotwo
    jsp- access the session bean at the same time. And, of course, it´sgoing to
    be the same instance of the session bean..... what will be the behaviourin
    this case?. Will the requests be serialized, an exception will be thrownor
    the EJB will be destroyed?. Not very sure of what would happen. Isuppose
    there could be some problems with this-. I would appreciate any help.
    Many thanks. Best regards.--
    Dimitri

  • 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

  • Creating multiple stateful session beans from a java client. (EJB 3.0)

    I'm having difficulties with the following:
    To access the ShoppingCartBean, I have to put the following annotation in my standalone java client:
    @EJB
    private static ShoppingCartRemote shoppingCartBean;
    The static must be there, thus only one ShoppingCartBean will exist within my java client. But as the ShoppingCartBean is a stateful session bean, I want to be able to get different beans of the same type.
    What is the correct way to do this in EJB 3.0?

    Great question. Because Home interfaces have been removed for the EJB 3.0 simplified
    API, stateful session bean creation happens as a side-effect of injection. However, the
    same is true of EJB 3.0 business interface lookups. The easiest way to create additional
    stateful session beans is to lookup the same dependency that was declared via your
    @EJB annotation.
    E.g.,
    // Assuming the declaring class is pkg1.ShoppingCartClient.java
    InitialContext ic = new InitialContext();
    ShoppingCartRemote scr1 = (ShoppingCartRemote)
    ic.lookup("java:comp/env/pkg1.ShoppingCartClient/shoppingCartBean");
    Note that the name relative to java:comp/env is the default associated with your
    @EJB annotation since the name() attribute wasn't used. Alternatively, you
    could have used :
    @EJB(name="scb") private static ShoppingCartRemote shoppingCartBean;
    InitialContext ic = new InitialContext();
    ShoppingCartRemote scr1 = (ShoppingCartRemote) ic.lookup("java:comp/env/scb");
    Yet another alternative is to declare the @EJB at the class-level. This just defines
    the dependency without any injection, which is fine if you want to create a bunch of
    them via lookup anyway.
    @EJB(name="scb", beanInterface=ShoppingCartRemote.class)
    public class .... {                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

Maybe you are looking for