Discussions

EJB design: Caching & EJB Patterns ..

  1. Caching & EJB Patterns .. (23 messages)

    Assuming that we have to cache a lot of data in the middletier because of performance reasons and repeated hits to same data by different requests, also assuming that my the business process will be designed using stateless session beans what would be the best pattern to design the cache layer objects and their interactions with stateless session beans? If the cache is read only with potential to grow based on requests what can be best implementation mechanism just as an single instance of an object.

    In this case stateless session beans need to get the reference of the cache object in the method parameters. Can a stateless bean hold a reference of the cache of the cache object be pooled as contained would the context switching?

    Also how do we handle reference of cache if the cache is split to be in an separate machine.

    If I have my own server side session manager for managing state data in the server, why would I use EJB Session beans because always I can pass the required data from getting my session and injecting them through parameters to session beans. In this case, I get over the stateful session bean passivation, activation performance droll.

    That's lot of questions, all thoughts will be appreciated.

    Thanks
    Madhu




    Threaded Messages (23)

  2. Caching & EJB Patterns ..[ Go to top ]

    You can use read-only or read-mostly entity beans for data caching.
  3. Caching & EJB Patterns ..[ Go to top ]

    I guess read only entity beans is a perfect idea. We had implemented the same in one of our project with wls5.1 and its works pretty well.
  4. Caching & EJB Patterns ..[ Go to top ]

    There are some anomolies related to read only entity beans. I suggest, you must look into these before you consider using them.

    pradeep
  5. Caching & EJB Patterns ..[ Go to top ]

    Just making statements doesn't help. Can u point out the anomolies related to readonly entity beans in this forum??
  6. Caching & EJB Patterns ..[ Go to top ]

    That's a good idea if you have much more reads than writes. We've used that pattern for building a portal (updates occurs once a day). What is the best solution if reads occurs as often as writes - for example if you need to store user profile information for the personalization reasons? You need to get information quick because this is *current* user information and you need to store info about each user action.
  7. Caching & EJB Patterns ..[ Go to top ]

    Hi,

    I am trying to implement Read-only EJBs. Do we need to implement the EJBCreate methods? The records are already existing in the database. The objective is to cache the records and not create new ones.

    Gopal
  8. Caching & EJB Patterns ..[ Go to top ]

    Madhu,
    I think the simplest way to implement the cache is to have a cache class wrapped around a hash table of application session objects. The wrapper will help you in fixing the size of the cache. So whenever the request comes, first look into this hash table. If you don't find it, get it from the database and then insert into the cache.

    Assuming that this cache is accessed only by the stateless session beans, you can make this cache as static and have static session services to access the cache.

    Yes, you may not use session beans at all. You can implement all the session bean objects as RMI server. But make sure your RMI server doesn't lead to a single point failure. For this reason you can use Weblogic's RMI server. However, I feel that from the long term perspective you should use session beans.

    Hope this helps...
    Pradeep
  9. Caching & EJB Patterns ..[ Go to top ]

    Pradeep,

      In case the cache that need to be built is user indcependent and if every user session need to use the same cache using HashTable is a HORRIBLE idea.

      Hash Table Get methods are synchronized. Before using any cache techniques better understand your requirements and code you are going to use.

      Why not use HashMap whose methods are not synchronized?

    Regards,
    Mettu.
  10. Caching & EJB Patterns ..[ Go to top ]

    Mettu,
    In Java community whenever people talk about HashTable or Vector, its understood taht they would be using HashMap or ArrayList. i.e. if people are using JDK1.3 they would definitely go for HashMap. Anyway the point of discussion here is not a perticular tool but the content.
    Also, at any point of time a website would reasonably have about 100-150 users(these are average figures) and caching the application session objects for these makes your system very efficient. There are lots of live j2ee projects who have implemented this architecture and are been very successful. I can give you pointers to these J2ee design, if you want.

    pradeep
  11. Caching & EJB Patterns ..[ Go to top ]

    IT works out fine in small projects pradeep. Imaging u need to cache 10MB of data. When 100 users are connected do u expect to have 1GB of session information?

    And think of In memory session replications in weblogic where u have 5 servers.

    And FYI using mentioning whether Hashtable or HashMap definitely make a difference. I know cache implementations going for toss just because developers used Hashtable.
    BTW HashMap is available since jdk1.2 u don't need 1.3.


    Thanks,
    Mettu.
  12. Caching & EJB Patterns ..[ Go to top ]

    Mettu,
    I don't disagree with you. The questions you have asked are of different nature and there are varoius ways to deal with them. However the point of discussion here is caching the session data and not content data which will be persisted. For example, my application session object will have a "currently selected folder". This kind of information is not heavy and I think the scheme would work perfectly. No web application on the earth can have a cashe of 10MB per user.This volume of cache would be preferably done on application level data which would be shared by all the users. Moreover, size of the cache is a configurable issue which is normally considered on the basis of memory, hardware used for deployment, cost, etc.

    Hope you understood.
  13. Caching & EJB Patterns ..[ Go to top ]

    To remind you, u didn't mention problems with Readonly entity beans.

    If you are taking of "currently selected folder" i bet u need to refer it as session data rather than cache.

    Mettu.
  14. Caching & EJB Patterns ..[ Go to top ]

    Again I don't disagree with you. This is purely a design issue. It's just not one "currently selected folder", there will be other currently selected entities(still not very heavy though). In my design I would not put this information in the HTTP session, I would rather create a application session object and pass it to my business services. The business services would then put it into the database as well as into the cache.
    Think about the situation where your application has a single point failure and all your session information goes for toss. In such cases, the "back over" app server can get back the session objects from database and resume the work, and the user wouldn't even know about it.

    I will definitely send you the anomolies with with Readonly entity beans in a moment(need to catch hold of a white paper on this that I had read a while back). In general people till Today haven't found a great success with entity beans. Also,If I need to map multiple tables, I got to do lot of coding with BMP beans. That's the reason people go with the mapping tool such as visual BSF.
  15. Caching & EJB Patterns ..[ Go to top ]

    Pradeep I would strongly recommend u to look at stateful session bean model for storing this session. Did u look at sun implementation of pet store. This would clarify lot of your doubts.

    People who doesn't have success with enity beans are mostly one's who use entity beans where they are not supposed to be used.

    BTW with session replication u don't need to get session info from DB. Heard of in memory replication?


    I guess we are completely deviating from original question.

    Mettu.
  16. Caching & EJB Patterns ..[ Go to top ]

    Mettu,
    An app server with in-memory replication feature are pretty expensive and not every app server provides support for this(I know ATG' dynamo app server support for this). You would need in-memory replication feature for heavily content oriented data (like a online news group agency), where the app server replicates the image of the complete memory. Sun' pet store implementation doesn't address all the business problems as such. If these freely available implementations can solve all the business problems, then I and you wouldn't have any job.
    Yes, we have slightly deviated with the core question. But what the heck! the discussion forums are ment to share knowledge of the related issues. Perhaps we could have posted this on a diffrent thread.

    -pradeep
  17. Caching & EJB Patterns ..[ Go to top ]

    Can u send some pointers related on Caching.I have seen your answers in Serversdide.
    Thanks
    Bye
  18. Caching & EJB Patterns ..[ Go to top ]

    A project I was working on had a similar requirement. We
    needed to store some read-only information to be shared by all users.

    The solution we used was to store it in a stateless session
    bean.
    The constructor for the session bean set the state to null.
    The cached information would be loaded (from XML configuration files) the first time it was requested by the
    client.

    There are probably some good reasons not to do it this way
    but it works which is the most important thing.
  19. Caching & EJB Patterns ..[ Go to top ]

    Hey guys!

    JNDI is not proposed to solve the problem of shared cash, nor any mentioned above approaches are.
    The answer depends on your server throughput requirements and budget of you project:

    If you need support for 1000 or more simultaneous users
    (or tps), your clustered server should have proper design with multiple ODBMS closely coupled with app. servers
    (it means running on the same machine),and in addition providing the best solution for shared/not shared middleware cash. Of cause using in-memory cash is also very worth to do.

    If you need support for 100 or less simultaneous users (or tps) and if your project's budget is too poor to purchase commercial ODBMS or Gemstone/J app. srv to provide future growth and scalability of your portal, you can do anything mentioned above.( but you can still use first scenario(but limited) with any free DBMS as the middle tier cash.)

    If the main (and the only) requirement of you project is the lowest cost per transaction, you made wrong choice - take a look at TPC site: COM+ TPM and MS SQL Server 2000 beats all others (including WebSphere 3.0 & Oracle 8.1.7) many times, especially as for $$ per transaction.
  20. Caching & EJB Patterns ..[ Go to top ]

    If anybody is interested, I wrote a small example which illustrates how to use Weblogic's read-only entity beans to implement non-transactional distributed object cache: http://dima.dhs.org/misc/readOnlyUpdates.jar. Any comments are welcome.
  21. Caching & EJB Patterns ..[ Go to top ]

    Pradeep,
    I am very much interested in knowing more about "Caching" the application wide stuff that you are talking about here. Can you send me some pointers.
    Thanks,
    Deepak
    dnautiyal@thebeast.com
  22. Caching & EJB Patterns ..[ Go to top ]

    Can you please post in this forum the J2EE design links/URL/White papers that explain what you are saying about caching issues on application session objects?

    Thanks much,

    -Victor
  23. Caching & EJB Patterns ..[ Go to top ]

    I thought that static instances were a big no no
    when using EJBs in a clustered environment
    as if you have a cluster you would have a number
    of virtual machines which couldn't access this
    static instance. I talked to a guy from BEA about
    this and he recommended using JNDI as a means
    of accessing globals from more than one virtual
    machine.
  24. Caching & EJB Patterns ..[ Go to top ]

    JNDI will do if object's size is reasonable for replication. If it is too large/complex you can implement singleton as a RMI object pinned to a single server in the cluster.