4 Replies Latest reply on May 5, 2005 3:57 AM by wildgeeza

    Read-mostly best practice on jboss4.0.1sp1

    wildgeeza

      I'm currently researching a clustered caching solution for deployment on jboss4.0.1sp1 and wondered if anyone feels like offering their two cents and/or personal experiences.

      The master version of my data resides in a mainframe, user updates typically come through our system. Given the small percentage of updates initiated from the mainframe side we can live with potential inconsistencies in those updates. The data is relatively static so time based invalidation across the cluster is also feasible.

      Solutions I've been pondering in current order of preference are:

      -Seppuku pattern with combination of beans/topic. Issue I see here is setup maintenance of a clustered topic.

      -A BMP/SFSB implemented with JBoss TreeCache. Not sure I want my codebase to be dependant on a specific version of TreeCache.

      -A BMP marked as clustered, I'm not sure this is possible/supported and how you would control granularity of replication. Presumably updates would fire on transaction boundary right ?

      -Bind data into HA-JNDI using PK as part of jndi name and periodically purge at regular time intervals. This is a hack I'll admit it but it would work.

      Thoughts, insight?
      Andrew



        • 1. Re: Read-mostly best practice on jboss4.0.1sp1
          siano

          If CMP is an option for you you could use the container configuration "Standard CMP 2.x EntityBean with cache invalidation" defined in standardjboss.xml. This configuration has an interceptor that removes a bean instance from the cache cluster-wide, once it is written.

          • 2. Re: Read-mostly best practice on jboss4.0.1sp1
            wildgeeza

            This would probably give the cleanest solution unfortunately the data to the mainframe is marshalled through a third party request/response style API which is why I was thinking BMP would be the way to go.

            If ther's an abstraction in the container where I could do mapping of entity fields CMP would give me the caching/transaction for free. The data is a simple bean with well defined key and nothing nested and no relationships.

            Does anyone know if I could write a custom connector or bridge to map to a custom persistence API? Are there any docs/samples covering this?

            Andrew

            • 3. Re: Read-mostly best practice on jboss4.0.1sp1

              I don't get your rationale of not to depend on TreeCache version. The minute you run clustering, you get vendor specific tie in already.

              -Ben

              • 4. Re: Read-mostly best practice on jboss4.0.1sp1
                wildgeeza

                Nothing against TreeCache, it looks great from what I've read, I simply didn't want the application codebase dependant on specific vendors API. I could abstract caching as a service, although wasn't that the point of JSR-107. Does anyone know where that stands nowadays I haven't been following is there a published API?

                I'm not sure I agree with you on being vendor specific once you run clustering. I know it's not in J2EE spec and obviously you have to account for replication/latency concerns but I should be able to design for a clustered Session or Entity bean and leave binding/policies as something that is dealt with in configuration right?

                BTW I don't want this to degrade into a religious thread I was simply looking for input on current best practice for 4.0.1sp1. By sounds of things JBoss line is to use TreeCache in BMP right Ben?

                Andrew