4 Replies Latest reply on Nov 19, 2008 11:00 AM by Brian Stansberry

    Issues with SFSB state replication and bean passivation

    Yong Zhang Newbie

      Hi,

      We are currently using Stateful Session Bean(SFSB) in jboss cluster(4.2.2). As the state replication is a costly operation, we implemented isModified() in bean class to always return false, we understand this will disable transparent failover, but the best possible performance is our top priority.

      However, we found that bean passivation was disabled as well by making isModified() always return false.

      Is there a way that we can disable state replication without affecting SFSB passivation? Thanks in advance.

        • 1. Re: Issues with SFSB state replication and bean passivation
          Yong Zhang Newbie

          Can anyone from Jboss confirm this, please? Thanks.

          • 2. Re: Issues with SFSB state replication and bean passivation
            Brian Stansberry Master

            Do you cache the EJB home and then reuse it to create multiple beans? If not, just don't configure your SFSB as clustered, as I don't think having it be clustered is doing anything for you.

            If that simple approach doesn't meet your needs, you can try replacing the clustered bean cache with the non-clustered one. E.g. in jboss.xml:

            <jboss>
            <enterprise-beans>
            <session>
             <ejb-name>nonreplicatedsfsb</ejb-name>
             <configuration-name>Non-Replicated Clustered SFSB</configuration-name>
             <clustered>true</clustered>
            </session>
            </enterprise-beans>
            
            <container-configurations>
            <container-configuration extends="Clustered Stateful SessionBean">
             <container-name>Non-Replicated Clustered SFSB</container-name>
             <instance-cache>org.jboss.ejb.plugins.StatefulSessionInstanceCache</instance-cache>
             <persistence-manager>org.jboss.ejb.plugins.StatefulSessionFilePersistenceManager</persistence-manager>
            </container-configuration>
            </container-configurations>
            
            </jboss>
            


            Note I've never tried the above. And I cut-and-pasted the xml from a few different places, so their might be some mistakes. But that shows the basic idea -- set up a special configuration that overrides the "Clustered Stateful Session Bean" config defined in conf/standardjboss.xml. The special config uses the non-clustered SFSB caching. At the top I'm showing an example of configuring a particular bean to use the special configuration.

            • 3. Re: Issues with SFSB state replication and bean passivation
              Yong Zhang Newbie

              Thanks for the reply, Brian.

              We do need load-balance, do we still have load-balance if we configure SFSB as a non-clustered one?

              • 4. Re: Issues with SFSB state replication and bean passivation
                Brian Stansberry Master

                Short answer -- maybe, depends on how you use your EJB. :-) Long answer:

                There are 3 areas of load balancing involved with SFSBs:

                1) Load balancing of the JNDI lookups of the EJB home. You get this by configuring your naming environment properties such that you are using HA-JNDI. Whether the things you are looking up are configured for clustering or not makes no difference at all here.

                2) Load balancing of calls made by the EJB home. You only get this if the EJB is configured as clustered. Hence my question about caching homes. If you don't cache homes, but look them up each time, the load balancing provided by looking up from HA-JNDI will give you much the same effect. But of course caching homes can be more efficient than looking them up all the time.

                3) Load balancing of the actual bean calls. Here a standard clustered SFSB doesn't really load balance; it sticks to a target server. It does handle failover, but without replication on the server side, failover won't work.