Invalidating an Entity bean Cache


EJB design: Invalidating an Entity bean Cache

  1. Invalidating an Entity bean Cache (4 messages)

    Hi gurus

    How do I do this cleanly.

    I have and Entity that has attributes A,B,C and D. These attributes are all read from database tables.

    A and B are read from Table 1
    C and D are read from Table 2

    So I have Entity Bean 1, this is loaded by the app server (perhaps by a findByPrimaryKey) method. This means that Entity Bean 1 is now a cache of the data in A,B,C and D.

    However while this entity bean is in the cache, via a session bean I change the data of C and D in table 2. This mean that Entity Bean 1 now has dirty data. So the question is how do I force the Entity beans to do and EJB Load.

    Also the data in C and D in table 2 may be shared by N number of entity beans so I may need to refresh N number of Entity Beans depending on which ones are in the cache.

    I only want to call EJB load for Entity beans currently in the cache and of these I only want to call ejb load for the ones that refer to the changed data.

    Cheers Peter
  2. the situation is this.

    this is the current data model

    I have and entity bean called "Content" this repsents 1 row in a table called "content". The content enitity bean can have N number of images (corresponds to n number of rows in the images table) and N number of text blocks (corresponds to n number of rows in the text table).

    However images and text blocks are independent of content. Content is only a grouping of these assets if you like. So we get a many to many relationship.

    1 content can reference many images
    1 image can be referenced by many content.
    (same for text)

    so when a content entity bean loads up it loads into its attributes all the data from the images and text that it references. So lets assume all this data is now in a cache.

    if i then change the data in an image or text independently of the entity bean (perhaps by a session bean) then the data that is cached in the entity bean is dirty (does not match what is in the database). SO how do i notify the entity bean to refresh it's self ?

    Another model you hinted on was that Image and text could be enitity beans. They are certainly independent enities (qualify as enities). However i consider them to be too fine grained. For example text block could be as small as "hello this is a sentance" which is just a small string and so wrapping this small string in an entity bean seem way too much overhead. But the flip side is it would so the cache problem.

    the session bean would do updates via the image and text beans and so they would always contain the correct data. And content would get the data from the image and text entity bean each time. However if the content has 50 text block and 50 images that is 100 calls (one to each of the entity beans that represent this data), which as you see is a major overhead

    Any thoughs on how i best model this.....

  3. Why dont you represent text and image as entity beans?
  4. The way i see it is ....

    The more entity beans i have then the more remote calls are needed.

    If i model the text and images as entity beans then this multiplies the remotes calls.


    Content entity bean has 10 image EB's and 10 Text EB's

    when i load the content bean it will go like this.

    content.findByPrimaryKey(1); 1 romote call, 1 db call

    content.getAllData() pass back a value object, 1 remote Call

    --- this method internally calls the image and text EB's

    image.findByContentKey(1); return collection. 1 remote call, 11 db calls

    text.findByContentKey(1); return collection. 1 remote call, 11 db calls

    then for each of the text and image eb's returned i call getdata()

    eg image1.getdata() 1 remote call

    so finally to get a content with 10 images and 10 text

    i make 44 remote calls.
    i make (potentially, due to caching) 33 db calls...

    so this is my dilema of using all entity beans...

    what is the ratio of database calls to remote calls with respect to performace.

    Which is worse, more database calls or more remote calls.

  5. Cool. Did you try to run any tests?