Where to hold reference data from system tables


EJB design: Where to hold reference data from system tables

  1. Where to hold reference data from system tables (5 messages)

    Hi all

    I followed all those discussions on the Singleton Pattners and so forth, but didn't found a advice for my situation.

    Actually I am having a large amount of system tables, holding different lookup values. For each value there may be n values attached that contain the code mapping for other system.


    Table Sys_Gender
    Code Language Text
    m E Male
    m D Mann
    f E Female
    f D Frau


    Code Language EndSystem EndSystemCode
    m E MainFrame 00
    m D MainFrame 01
    m E SystemY 00445

    Further more I am having big amounts of meta data describing the fields of objects, loaded from different end systems.

    So to come done to the point, I am having a large amount of reference codes, and a large amount of meta information to objects.

    As this data is accessed all the time, I would like to cache it.

    At the moment I am using a RefCodeHandler EJB Session Bean holding them, but I don't like that approach.

    Anyone having some ideas?

  2. Premature optimization is... You should know this music. :-)

    As for me, non-caching SLSB in front of CMP beans with commit option A is quite ok. Server already has a cache for your CMP beans. And as far as they are never modified commit option A is the best option here. Or, if they do modified very rarely then check your vendor docs for smth. like commit option D in JBoss 3.x -- timed cache.

  3. Maybe wrong description of problem[ Go to top ]

    Yeah I know exactly what you mean.

    What bothers me, is the fact, that most of the data read in the system, are not really known. They're only described by meta data. The main logic lies in an external system accessed via corba.

    Building up a session for the data description is far too expensive, so I am using meta data. Even more many products that have to be displayed in the system are no longer known by this external system, as they are no longer supported for new contracts. So I have to use meta data in most of the cases.

    This means that I am having far more meta data accesses than anything else. A central point in the system, is to have as less knowledge of the products as possible, to decrease maintenance in the front end system.

    So as my core data accesses are in that area, I am bit worried about finding the right design. I am not worried about performance in first.

    So I am searching a solution that allows me to handle a large amount of clients without reading the meta data from the database all the time.

    I am not that sure if my idea of using SLSB is the right one. So what I would like to get out of the discussions are different solutions to find the one that fits most.

    Sorry if this did not came out.
  4. If it's allowed to paraphrase you a bit, this sounds like: "I'm not talking about performance, I'm talking about scalability". However, these 2 goals are highly correlated :-).

    Well, it depends whether or not you have an EJB layer in your application. If not -- then read-only cache via regular singleton will be quite sufficient, IMHO. For example, if your app contains only Servlets / JSP with either POJO DAO for data access or Hibernate, then you can write some bootstrap ContextEventListener that initialize this singleton and populates cache.

    On other hand, if EJB tier is involved, then SLSB in from of CMP with commit option A is a viable solution. You'll get a kind of singleton as well, however the architecture design will be not so obvious due to several parties involved.

    1. When you say that CMP bean is managed with commit option A, then app. server assumes that it is the only party who ever modifies data. As long as your data is more or less a metadata/dictionary (i.e. never updated), then, in fact, app. server will only load data only ones in it's internal cache.

    2. Next step, an SLSB access CMP beans. From previous point it's obvious that this will not force any JDBC queries. However, app. server have to "incarnate" a cached rowset data to EJB instance. Again, if pool specified for CMP beans is quite sufficient, it will occur only once. On other hand, if there are too many instances need to be incarnated, then app. server will provide you far more efficient pooling strategy, then you can write yourself (unless you are genius :-)

    3. There is no serious performance impact for pooling of SLSB themselves. Sure, if one client request to SLSB grabs instance N1, and other client try to do the same, then server will assign SLSB instance N2 to handle second request. As far as these instances are pooled and extremely lightweight there is no any significant performance impact that affects scalability of solution.

    4. The scheme could be further extended. If client does not need full set of information from CMP bean, or you'd like to avoid even calls to entity beans or value object creation, then you can setup internal structure in SLSB for this case (and this will be really performance optimization ). Just as simple as unsynchronized java.util.Map that maps possible SLSB method parameter(s) or CMP PK to necessary subset of fields of VO.


  5. Thanks for the description[ Go to top ]

    Thanks for the information. Indeed I am using EJB's but I was not sure if I should use CMP or only SLSB doing one huge lookup on first access... So I'll try the SLSB / CMP combination...
  6. Hi!

    I solved the problem with cache (including regular refresh!) of reference data in a project this summer. I have been working with caches and initiation of caches (and other things) in at least three projects, and the solution from this project worked very well.

    The cache can be used in the Servlet container as well as in the EJB container (although we didn't use EJBs in the project). It also works in a stand-alone JVM. (We executed JUnit unit tests from the Java IDE directly.) The solution is a value object-based approach with data access objects reading the data into the cache. The reload is made with a java.util.Timer object created in a Servlet with <load-on-startup> element defined. (The start-up is a bit more complex in the EJB container.)

    A description of the solution requires some images, text and sample code, so I cannot describe it in this text box format. However, if you give me a mail address, I can send you some documentation and sample code (with the Gender class as example).