Caching Read-Only 'UI' Data


EJB design: Caching Read-Only 'UI' Data

  1. Caching Read-Only 'UI' Data (5 messages)

    Hi all,

    I am working on an approach to storing our apps "mostly static" UI data (navigation links, logo gifs, colors, etc.) within some data structure in the application server. This data will not change very often and if it does it will be acceptable to restart all of our clusters until they are all in sync. If my application wasn't using EJBs I'd just cache this data into a singleton class and access it through methods on that class.

    In my current case we are using EJBs to perform the business logic for the application. Since the data the UI is displaying is based on who the client is (and other factors) it would make sense to put this data in a stateless session bean with business methods to retrieve it.

    Should I be concerned with the overhead of calling this stateless EJB for every page that is served out. Also, if i do put this data into a stateless session bean will the app server create many copies of this read-only data?

    Simply put - what is the best method for caching read-only data within an EJB web application? Should I do this within my tag libraries for the best performance, or is there a pattern for creating a read-only session bean?



    Threaded Messages (5)

  2. Caching Read-Only 'UI' Data[ Go to top ]

    These are some of your options IMHO:

    1) Continue to use singleton. You can still use it in an EJB environment.
    2) Use a read-only entity bean.
  3. Caching Read-Only 'UI' Data[ Go to top ]

    I think the best approach depends on the type of application you are writing, and no one can asses it better than you. However, here are a couple of factors I would take into account:
    - Try to analyze your design and figure out which layer of your application the data belongs to. For instance, if the data contains things like GIF urls for HTML pages, style-sheets, etc, the data belongs to the View. It's a good design approach to keep View specific data away from the application tier (i.e, EJBs) so that your components remain reusable. If that is the case, I would put the data in the web-server using JavaBeans/taglibs/whatever.
    If the data contains information that should be accessible to the application tier (i.e, user name, email, etc) I'd put it in the EJB tier.
    - There is a useful pattern for read-mostly caches in the Patterns section called A.C.E. It is somewhat difficuilt to implement though, and if you can bare restarts whenever the data changes you don't need it. Again, the choice between SLSBs and entity beans depends on the data and the way it is used. I get the feeling you are more into the web-server approach. If you want more details about the EJB one post again, I'll try to help.

  4. Caching Read-Only 'UI' Data[ Go to top ]

    I suggest the best approach would be to use rules engine with its Repository for the links and GIF. Thus rules engine can do Role based processing and return the static data by having its own cache logic. Implementing your own cache logic might be bit difficult, to find out when the data is stale. If you pump your own Static Content into the Repository then the best approach would be to use JMS and Singleton. Thus Singleton won't duplicate the static data and JMS will let you know when the content changes were chamged.

  5. Caching Read-Only 'UI' Data[ Go to top ]

    You mentioned the following "There is a useful pattern for read-mostly caches in the Patterns section called A.C.E"

    Can you please tell me where do I find the literature for the same.

    Is there any way that we can implement this pattern with complete APP server independence

  6. Caching Read-Only 'UI' Data[ Go to top ]

    The pattern is described in the patterns section of this site. I don't know any other sources where you can find information about it (aside from a WebLogic specific pattern mentioned in the ACE description).
    As for server independence, there is no way to achieve that unless you give up entity beans for reading data. That means that you cant use CMP. If you use BMP with a seperate data access object doing DB related operations, this shouldn't be a big problem.
    In the pattern thread I mentioned some potential problems that can arrise and possible solutions.

    However, according to what I understood from your post, it probably won't be worth your trouble to implement this massive pattern. As I mentioned, if you tolerate cluster restarts when data changes this pattern is utterly useless.
    Further, I would strongly consider holding the data on the web-tier. Again, according to what I read from your post, it sounds like a prefferable alternative.
    Anyway, if you have specific questions about ACE you are welcome to post them in the ACE thread. That way other people could comment, and people with similar problems to your would benefit.