6 Replies Latest reply on Oct 18, 2004 2:24 PM by patelj

    How to make EJBHome stub reference survives JBoss restart

    patelj Newbie

      Hi,

      I am using JBoss 3.2.2.
      I have EJBHome stub references in the Service Locator class (Service Locator pattern) in a remote client. If the JBoss is restarted, then this home stub references are no longer valid and I have to refresh the service locator cache.
      Is there a way to make the remote home stub survives Jboss restart (and also the redeployment of EJB on the server) ?

      thanks,
      Jagat

        • 1. Re: How to make EJBHome stub reference survives JBoss restar
          jae Master

          redeployment of an ejb can be handled, see this wiki page http://www.jboss.org/wiki/Wiki.jsp?page=HotDeployClassCastExceptions - you will need to repackage your ejb so that the only thing that gets redeployed is the implementation class, and not the remote/home interfaces. if you change the actual interface, this does not work.

          as for surviving a server restart, i don't believe this is possible. couldn't you add extra code to your service locator to catch the exception that occurs and attempt to refetch the home interface again, and then if that fails, kick out an error? [/url]

          • 2. Re: How to make EJBHome stub reference survives JBoss restar
            patelj Newbie

            Hi Jae:

            I want to avoid to add code in Service locator to refresh its cached EJB Home references because that will lead to all the classes that uses Service Locator will have to call refresh() method on it once they detect that their EJB reference is stale. I read in Floyd Marinescu's EJB Design Pattern book (EJBHomeFactory pattern) that majority of the application server allow the EJB home stub to survive the server restart and EJB redeployment. I tried on JBoss 3.2.2 and it did not worked. So I thought if there is some configuration that needs to be done to make this happen.

            thanks,
            Jagat

            • 3. Re: How to make EJBHome stub reference survives JBoss restar
              jae Master

              jboss uses dynamic proxies for their stubs (which is why you don't need to compile them), so i'm not really sure this is possible.

              but you're right, now that i think about it, if you're pulling cached interfaces out of the servicelocator, you're not going to know the refs are stale until you try to invoke a method on it.

              if you repackage such that your interfaces aren't "cycled" when you redeploy the ejb implementation class, everything should contine to work normally. you could also try turning on "pass by value" instead of "pass by reference", although you will see decreased performance using this.

              could you provide a bit more info on the client app using the service locator? there may be other "creative" ways to deal w/ this issue.

              • 4. Re: How to make EJBHome stub reference survives JBoss restar
                patelj Newbie

                Hi Jae:

                Consider these pseudo code of client Class (Foo) that uses Service Locator. Imagine that the callEJB() was called atleast once succesfully. Then the app server restarted and the callEJB() is called again. We wont be able to call the ejb unless the service locator cache is refreshed somehow or the ejb home references survives the server restart. I want to avoid the first option if possible.

                Class Foo
                {
                private EJBClass ejbRef = null;

                ...
                public void callEJB() throws ...
                {
                try {
                initIfRequired();
                ejbRef.callMethod();
                }
                catch( NoSuchObjectException e )
                {
                // EJB reference is stale. Reset the ejb ref to null so that
                // next time it will be recreated. But the service locator has
                // cached the ejb home reference and they are stale, unless
                // app server survives them upon restart or we refresh
                // the cache.
                ejbRef = null;
                }
                }

                private void initIfRequired() throws ...
                {
                if (ejbRef != null)
                return ejbRef;

                // Service locator will return cached home reference if it has one.
                EJBHomeClass c = serviceLocator.getHome( "jndiName", EJBHomeClass.class );

                ejbRef = c.create();
                return ejbRef;
                }
                }

                thanks,
                Jagat

                • 5. Re: How to make EJBHome stub reference survives JBoss restar
                  jae Master

                  i understand what you're getting at, but from my understanding of how jboss's classloader works, and the fact that they use dynamic proxies for the ejb stubs, i don't think you have any other options then to reload your cache.

                  at this point, unless someone claims otherwise, i think you need to look at what options are available for you to reload the cache in a way that is least intrusive to code you have already written, hence my asking for you to describe what type of client app you are using -ie: is it a webapp run under tomcat, a "thick client", etc.

                  is this a development only type issue? as i have stated before, if you repackage your code and are only changing the implementation class, you should be able to redeploy ejb changes w/o any ill effect to the cached interfaces that you have.

                  • 6. Re: How to make EJBHome stub reference survives JBoss restar
                    patelj Newbie

                    Hi Jae:

                    Sorry I misinterpreted your initial question. I am having a stand-alone "thick" client application.

                    Your solution for ejb redeployment seems fine to me (basically will require changes to the packaging). But ejb redeployment is not that critical for us then the server restart. If there are no other ways then we will have to figure out a way to refresh the cache in less intrusive way as you indicated.

                    thanks,
                    Jagat