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.

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

  • GUID generation issue, SYSUUID always returns the same value.

    Hi,
    I'm using "SELECT SYSUUID FROM DUMMY" to get a guid value but it always return the same value.
    What should I do to get a unique value each time I execute the query above.
    Thanks.

    I thought I had the same problem and I found that if you generate multiple UUID's in the same SQL, it they will be the same.  If you make multiple calls, you should get multiple UUID's. 
    Try this:
    SELECT SYSUUID as UUID1 FROM DUMMY;
    SELECT SYSUUID as UUID2 FROM DUMMY;
    I get the following results:
    UUID1 = 538632FD7EA20426E10000000A3F10A9
    UUID2 = 538632FE7EA20426E10000000A3F10A9
    Notice that the strings look almost identical, but the 8th character on UUID1 is a D and the 8th on UUID2 is a E.
    Jim

  • 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

  • Does JNDI always return the same DataSource reference for a connection pool

    Hi,
    In my project, I have a class called DBConnect which has a method called
    getConnection(). This method returns a data base Connection object from the
    pool. I am doing this to avoid replicating code.
    Here, each time a database connection is required this method looks up for
    the pool using JNDI , gets the DataSource and then gets the data base
    connection.
    What I want to know is that, can I get this DataSource reference only once,
    store it in an instance variable and use the same value for getting the
    connections when ever needed. This wud reduce the overhead of making the
    lookup each time.
    but wud this lead to probs. is there a threat of having a stale reference.
    Or is there a better way to do this.
    Thanks,
    Manohar

    Hello,
    In our EJBs, we successfully cache the DataSource object as an instance
    variable. Since bean access is synchronized, the concurrency issue Jeff
    Wang mentioned is dealt with.
    Eron
    "Manohar" <[email protected]> wrote in message
    news:[email protected]..
    Hi,
    In my project, I have a class called DBConnect which has a method called
    getConnection(). This method returns a data base Connection object fromthe
    pool. I am doing this to avoid replicating code.
    Here, each time a database connection is required this method looks up for
    the pool using JNDI , gets the DataSource and then gets the data base
    connection.
    What I want to know is that, can I get this DataSource reference onlyonce,
    store it in an instance variable and use the same value for getting the
    connections when ever needed. This wud reduce the overhead of making the
    lookup each time.
    but wud this lead to probs. is there a threat of having a stalereference.
    >
    Or is there a better way to do this.
    Thanks,
    Manohar

  • Deploy multiple instances of the same stateless session EJB

    I have a stateless session bean.
    The methods on the bean operate against DB tables.
    Q: Can I deploy multiple instances of the same stateless session bean, but specify a different JNDI/datasource name in the deployment descriptor?
    The method calls are all enclosed within a single invocation, just that I need to hit different databases (all with the same schema), and Id like to be able to lookup the EJB via a different JNDI name, and have the exact same functionality, just against different deployed datasources.
    Does the spec allow/support this?
    If not, any suggestions as to how to achieve this sort of functionality?
    Im using JBoss 3.2.1 on Solaris, so Im not sure whether or not this is a JBoss "issue" or a limitation of the EJB Spec (or me being just plain wrong and trying to do something the "wrong way")
    Nick

    I have a stateless session bean.
    The methods on the bean operate against DB tables.
    Q: Can I deploy multiple instances of the same
    stateless session bean, but specify a different
    JNDI/datasource name in the deployment descriptor?
    The method calls are all enclosed within a single
    invocation, just that I need to hit different
    databases (all with the same schema), and Id like to
    be able to lookup the EJB via a different JNDI name,
    and have the exact same functionality, just against
    different deployed datasources.
    Does the spec allow/support this?
    If not, any suggestions as to how to achieve this sort
    of functionality?
    Im using JBoss 3.2.1 on Solaris, so Im not sure
    whether or not this is a JBoss "issue" or a limitation
    of the EJB Spec (or me being just plain wrong and
    trying to do something the "wrong way")
    NickI haven't done it but judging from the deployment descriptors yes.
    For example if I have two bounded datasources java:/Database1 and java:/Database2
    Lets say I have a session bean called MySession, then in your ejb-jar.xml you would have (notice that the desc, display, and ejb-name are the only differences)
    <session>
    <description>MySessionAlpha</description>
    <display-name>MySessionAlpha</display-name>
    <ejb-name>MySessionAlpha</ejb-name>
    <home>com.mycorp.MySessionRemoteHome</home>
    <remote>com.mycorp.MySessionRemote</remote>
    <local-home>com.mycorp.MySessionLocalHome</local-home>
    <local>com.mycorp.MySessionLocal</local>
    <ejb-class>com.mycorp.MySessionFacadeBean</ejb-class>
    <session-type>Stateless</session-type>
    <transaction-type>Container</transaction-type>
    <resource-ref>
    <res-ref-name>jdbc/DataSource</res-ref-name>
    <res-type>javax.sql.DataSource</res-type>
    <res-auth>Container</res-auth>
    </resource-ref>
    </session>
    <session>
    <description>MySessionBeta</description>
    <display-name>MySessionBeta</display-name>
    <ejb-name>MySessionBeta</ejb-name>
    <home>com.mycorp.MySessionRemoteHome</home>
    <remote>com.mycorp.MySessionRemote</remote>
    <local-home>com.mycorp.MySessionLocalHome</local-home>
    <local>com.mycorp.MySessionLocal</local>
    <ejb-class>com.mycorp.MySessionFacadeBean</ejb-class>
    <session-type>Stateless</session-type>
    <transaction-type>Container</transaction-type>
    <resource-ref>
    <res-ref-name>jdbc/DataSource</res-ref-name>
    <res-type>javax.sql.DataSource</res-type>
    <res-auth>Container</res-auth>
    </resource-ref>
    </session>
    But now in the jboss.xml, we will have the following elements. What you may notice is that are bound to different remote and local jndi names. But the resource bindings are very different. The res-ref-name stays the same, but the jndi-name are different. I think this will work for you.
    <session>
    <ejb-name>MySessionAlpha</ejb-name> <jndi-name>ejb/com/mycorp/MySessionAlphaRemoteHome</jndi-name> <local-jndi-name>ejb/com/mycorp/MySessionAlphaLocalHome</local-jndi-name>
    <resource-ref>
    <res-ref-name>jdbc/datasource</res-ref-name>
    <jndi-name>java:/Database1</jndi-name>
    </resource-ref>
    </session>
    <session>
    <ejb-name>MySessionBeta</ejb-name> <jndi-name>ejb/com/mycorp/MySessionBetaRemoteHome</jndi-name> <local-jndi-name>ejb/com/mycorp/MySessionBetaLocalHome</local-jndi-name>
    <resource-ref>
    <res-ref-name>jdbc/datasource</res-ref-name>
    <jndi-name>java:/Database2</jndi-name>
    </resource-ref>
    </session>

  • Call existing stateful session bean in different servlets

    hello,
    we are implementing a shopping cart for our online dvd store in netbeans 5.5.1 and ejb 3.0.
    for that we use a stateful session bean, which is created when a user is logging in for connecting the user-entity to the bean.
    after logging in, the list servlet, which displays a list of all available dvds, is shown. after clicking the "add to shopping cart" button, the cart servlet with a list of all added dvds is shown. in this servlet we want to reactivate the existing stateful session bean. is this possible? and when it's possible, how is it possible? ;)
    our sessionbean with initialize() method:
    @Stateful
    public class CartBean implements Cart {
        UserEntity user;
        List<DVDEntity> contents;
        public void initialize(UserEntity user){
            System.out.println("Warenkorb erstellt");
            this.user = user;
            contents = new ArrayList<DVDEntity>();
    }thx!
    Edited by: licherpremium on Nov 8, 2007 6:35 AM

    hello,
    we are implementing a shopping cart for our online dvd store in netbeans 5.5.1 and ejb 3.0.
    for that we use a stateful session bean, which is created when a user is logging in for connecting the user-entity to the bean.
    after logging in, the list servlet, which displays a list of all available dvds, is shown. after clicking the "add to shopping cart" button, the cart servlet with a list of all added dvds is shown. in this servlet we want to reactivate the existing stateful session bean. is this possible? and when it's possible, how is it possible? ;)
    our sessionbean with initialize() method:
    @Stateful
    public class CartBean implements Cart {
        UserEntity user;
        List<DVDEntity> contents;
        public void initialize(UserEntity user){
            System.out.println("Warenkorb erstellt");
            this.user = user;
            contents = new ArrayList<DVDEntity>();
    }thx!
    Edited by: licherpremium on Nov 8, 2007 6:35 AM

  • Why my vector() always always return the last record?

    Whenever i uses Vector, my whole vector always return the last element.. why?? Anyway to solve this?
    some examples of my codes..
    (String)rowVector.elementAt(2)
    My rowVector vector always return the last element..
    while(rs1.next())
    Vector rowVector = new Vector();
    for (int currentCol = 0; currentCol < numCols; currentCol++)
    rowVector.add(rs1.getString (currentCol + 1));
    tableData.addElement(rowVector);

    That means that every element in the Vector refers to the same object. I am surprised that your JDBC driver does not return different string objects for each call, but to work around that, try this:
    rowVector.add(new String(rs1.getString (currentCol + 1)));

  • Is a Servlet-Filter which serializes requests in the same user session ok?

    The Servelt specification states that the Web-Application is itself responsible for synchronizing access to HttpSessions. It is from the serversite not possible to prevent multiple threads to access the same HttpSession (i.e. the user could always open a second window, retransmit a form etc). My assumption is that while this does not happen often it can happen and therefore I think each access to the HttpSession must be synchronized. For a further discussion see http://forum.java.sun.com/thread.jsp?forum=4&thread=169872 .
    Concurrent programming is generally complicated and errorprone. At least in developing JSPs it is inconvenient and easy to forget. My Web-App uses often HttpSession and it can be used in different not predefined places, so I had the idea to implement a ServletFilter which serializes threads which happen in the same session. This involves certainly some overhead. However for the advantages of easier code maintains and higher consistency I am ready to pay this overhead.
    My question is generally what you think of this approach and second whether the way I implemented the Filter works.
    The Filter actually generates for each Request an HttpServletRequestWrapper which intercepts calls to getSession and on call aquires a Lock so that other threads have to wait for the same Session. The lock is released when the doFilter method of the Filter returns. So threads run concurrently until the first access to the Session and from there they are serialized until the end of the Request.
    For the details I will give the code for the Filter and the Wrapper (that?s all the code needed except the ReentrantLock which is Doug Lea?s implementation http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html )
    the Filter
    public class SessionThreadFilter implements Filter
      public static final String MUTEXT_IN_SESSION_KEY = "org.jaul.filter.SessionThreadFilter.MUTEX";
      //constructor, init, destroy methods do nothing
      public void doFilter(ServletRequest reqIn,ServletResponse res,FilterChain filterChain)
        throws IOException, ServletException
        //if req not instanceof of HttpRequest don't do anything
        if (!(reqIn instanceof HttpServletRequest))
          filterChain.doFilter(reqIn, res);
        } else
          HttpServletRequest req = (HttpServletRequest) reqIn;
          //We use a HttpRequestWrapper each time a user accesses
          //through this
          //Wrapper a Session is Lock is aquired. The filter method returns
          //the lock if it exists is released
          //each thread needs it's own wrapper so the wrapper itself
          //doesn't have to be synchronized
          SessionThreadRequestWrapper wrapper = new SessionThreadRequestWrapper(req);
          try{
            filterChain.doFilter(wrapper, res);
          }finally{
            ReentrantLock lock = wrapper.getLock();
            if (lock != null && lock.holds() != 0)
                       lock.release(lock.holds());
    the Wrapper
    final public class SessionThreadRequestWrapper extends HttpServletRequestWrapper {
      private ReentrantLock lock = null;
       * Constructor for SessionThreadRequestWrapper.
       * @param arg0
      public SessionThreadRequestWrapper(HttpServletRequest req){
        super(req);
       * @see javax.servlet.http.HttpServletRequest#getSession()
      public HttpSession getSession(){
        return getSession(true);
       * @see javax.servlet.http.HttpServletRequest#getSession(boolean)
      public HttpSession getSession(boolean construct){
        //this will get the session an the lock
        HttpSession session = getLockFromSession(construct);
        if (session == null) return null;
        //get a lock on the mutex
        try{
          lock.acquire();
        } catch (InterruptedException e){
          throw new IllegalStateException("Interrupted while thread waiting for session");
        //now we check again if the session is still valid
        try{
          session.getAttribute(SessionThreadFilter.MUTEXT_IN_SESSION_KEY);
        } catch (IllegalStateException e){
          //again we go recusively but first release the lock
          lock.release();
          lock = null;
          return getSession(construct);
        //after you got the lock you can return the session
        return session;
       * gets the lock from the session
       * @param construct
       * @return HttpSession
      private HttpSession getLockFromSession(boolean construct){
        //test if it is a new Session
        HttpSession session = super.getSession(construct);
        //if is null no session was realy requested
        if (session == null) return null;
        //otherwise try to get the lock if necessery construct it
        //syncrhonized over session
        synchronized (session){
          //this migth throw an Exception if the session has been
          //invalidated in the mean time
          try{
            lock = (ReentrantLock) session.getAttribute(SessionThreadFilter.MUTEXT_IN_SESSION_KEY);
            if (lock == null){
              lock = new ReentrantLock();
              session.setAttribute (SessionThreadFilter.MUTEXT_IN_SESSION_KEY, lock);
            return session;
          } catch (IllegalStateException e){
            //the session has been invalidated before we tried to get the
            //lock we recursively call getLockFromSession
            //( assumption checked with Jetty: if the session is invalidated
            //and getSession is called on the thread a new valid session
            // should is returend)
            //I hope sometime you should get a valid session but I am not
            //sure. This is crucial for breaking of the recursion
            lock = null;
            return this.getLockFromSession(construct);
      /** used by the Filter to get the lock so that it can release it
      ReentrantLock getLock(){
         return this.lock;
    }As stated I would be very thankful if you could check the code and give some commends.

    synchronized (session){Are you sure that the session instance returned by two
    concurrent calls to getSession(...) are the same? I
    think that tomcat for instance may return different
    instances for the same "logical " session, which would
    break your scheme I think... Thank you (I did not know that on Tomcat). The same thing could also occur if another filter wrapped the Session.
    That's indeed a problem,which I have already adressed in another thread, but did not get an answer. ( http://forum.java.sun.com/thread.jsp?forum=33&thread=412380). The already cited thread http://forum.java.sun.com/thread.jsp?forum=4&thread=169872 adresses the same problem, but the discussion there ends with the recomandation that you should synchronize on HttpSession as I did it. Also in other forums I've read so.
    However like you I've at least strong doubts in this approach, so now my question is on what should I than generally for any access in any web-app syncrhonize the access to Http-Session as demanded by the Servlet specs.
    A few not realy satisfying answers:
    Synchronize on the HttpSession itself: I think still the best approach, but as you say is it guaranteed that the same instance of an HttpSession is given to each Request (in one Session)?
    Synchronized on the HttpServlet: This only works if no other servlet (or jsp) accesses in the session the value with the same key ( of course only if the session itself is threadsave). In case of ThingleThread it is not possible at all there can be multiple instances (you could use a static variable)
    Holding the object to synchronize on in applicaton scope or session scope: This obiously doesn't help, because somehow you have to obtain the lock and at least there you need another synchronize.Holding in application socpe is slow a static variable lock would be better there.
    Synchronize on some static variable: This will work, but is very slow (each request not only in the same session would synchronize on this).
    Hold a map in application scope, which holds for each Session-key a lock: Is probably faster than the static variable thing. However the access and the management of the Map (removing of unused locks etc.- Mabe you could use a WeakHashMap to collect the locks for not used keys anymore) is time consuming too and again the map must be accessed syncrhonasly by all requests.
    Syncrhonize on the Filter (only in my case): This is as slow as the static variable approach because each request will use the same lock the one instance of the Filter.
    So synchronizing on the session is propably the best approach if the same attribute name is accesed by different servlets. However if you say that some Web-Containers return different HttpSession instances for the same Session (which is legal according to the specification) this of course does not work.
    So I have realy no clue on what to syncrhonize than. Now help is not only neede on my Thread serialization filter but on my generally Servlet prgromming.
    May be you could help me for another synchronization aproach.

  • Where does Sting to IP get the net address if the computer is disconnected from the net? It should return the same I

    P/Net address� it did not change. Internet Protocal(TCP/IP) Properties did not change. When the network is physically disconnected, my VI after several runs returns 127.0.0.1. So, how do I get my IP address whether it�s connected to the network or not?Thanks in advance for your help.

    P/Net address� it did not change. Internet Protocal(TCP/IP) Properties did not change. When the network is physically disconnected, my VI after several runs returns 127.0.0.1. So, how do I get my IP address whether it�s connected to the network or not?If you're getting a dynamically assigned IP address from the network, then String to IP will return that IP but it may not be constant. See if TCP/IP properties are set to "Obtain an IP address automatically". If you disconnect from the network, then the IP address will default to something and I wouldn't be surprised if the default is 127.0.0.1. If you want to always have the same IP, then the ICP/IP properties should be changed to use a fixed IP but you'll certainly need to check with your IS department before doing so.

  • Hi. My husband and I have always shared the same iTunes account.  Since installing iCloud, all our contacts and calenders have merged on our iPhone 4, which we do not want.  How do I rectify this? Does my husband need to set up his own apple ID?

    Hi. My husband and I have always shared the same iTunes account.  Since installing iCloud, all our contacts and calenders have merged on our iPhone 4, which we do not want.  How do I rectify this? Does my husband need to set up his own apple ID?  If so, where do I need to change his email address info, so that his calender and contacts remain his?  Thank you

    You can continue to use the current AppleID for iTunes, but your husband can create a new AppleID to use to create a new iCloud account that will be his own and not overlap with yours.  If you do not have another email address to use for an AppleID, just get a free Gmail account and use that.
    You can have as many AppleIDs as you want (or at least, as many as you have email addresses for).  You can use a separate AppleID for the store, another for iCloud, and even another for iMessage if you wish.
    You will want to keep the current one as the shared one for the store as all your previous purchases are permanently tied to it, and thus you need that AppleID to update or redownload your current purchased content.

  • I keep getting notified that there is an update to Firefox Weather 2.0.1 but when I try to install it I always get the same "download error" -228. How do I get around this?

    I don't think additional details will help since I don't have any. I have tried repeatedly to install this update and always get the same result which I have already detailed. This is technically an Add-On but I was given no place to ask questions about it.

    See if this helps you. <br />
    https://support.mozilla.com/en-US/kb/unable+to+install+add-ons#Download_Error_228

  • How do I set a fixed page size in Muse so that the window always stays the same size

    how do I set a fixed page size in Muse so that the window always stays the same size

    Hi Aish & thanks for responding;
    I would like the window size to stay the same for the entire site and not be
    able to scale to drag & scale it. ie 950 pixels x 500 pixels.
    Thanks,
    JB
    On 12/4/14 3:30 PM, "Aishvarya Raj Rastogi" <[email protected]>

  • Make a file extension to open always with the same app

    Hello, do you know how can I make a file extension to open always with the same app. So far I have been doing it by double click > open with > other > and then mark open always with this app, BUT
    I do not want to do this very time with all the same file extension I have in my hard disk, is there any way, like in windows, to select and preset a determined app to always open all files with the same extensión in my hard disk??
    Actually what I´m experiencing and would like to change is to open always .pdf extensión with Acrobat and not with Preview
    Thanks very much in advance for your help!!

    OK!!!!
    Got it!!!
    Thanks anyway!!

  • Is there any way I can program "Capture" to save pnp.picts always under the same name, without a date ?

    Is there any way I can program "Capture" to save pnp.picts on the desk, but always under the same name, without a date ?
    It may be sound weird, but I use it in a very special way, and I would like, like photoshop, that capture just replace
    the previous pict by the new one..without any warning.
    Pierre

    There is no way to go back from an XFA form to an Acroform even with Acrobat Pro, still less with Acrobat. You either need to remake the form, or change your plans to use a third party viewer - Adobe have an excellent range of programs they would like you to use!

Maybe you are looking for