Discussions

Performance and scalability: EJB Caching Issues

Bookmark and Share Get thread feed

  1. EJB Caching Issues (9 messages)

    Hi all,

    I plan to use session beans as front-ends to load and store objects from and to a RDMBS. Basically, instead of using session beans to wrap entity beans, I would like to use session beans to wrap "database" objects.

    What is the recommended way to cache the loaded objects? For load operations, I would like to hit the database server as rarely as possible.

    I do not plan to use entity beans.

    Thanks,
    Anh
    Reply to this

    Threaded Messages (9)

  2. EJB Caching Issues[ Go to top ]

    Why not use Entity Beans? (unless your caching schema is drmatically different from what is being offered by your EJB container - in which case you probably do not need session beans or EJB container - just implement your caching logic and database accesses yourself).
    Reply to this Reply to original

  3. EJB Caching Issues[ Go to top ]

    To me, the overhead of entity bean is too heavy that even after we do some optimization like using session bean to wrap the entity bean and use isModified() method(in weblogic) to limit the database calls, we still get too many accesses to the DB. Using a session bean with proper caching seems to be a little bit difficult to program but we only make DB calls when it's necessary. Anybody can have some idea that how can we get rid of excessive DB access when using entity bean?
    Reply to this Reply to original

  4. EJB Caching Issues[ Go to top ]

    Well, Entity beans are a pain to use and quite inefficient because more often than not, they hit the database server more than necessary.

    Reply to this Reply to original

  5. EJB Caching Issues[ Go to top ]

    Anh,

    Did you specify the level of transaction isolation? The number of times that an entity accesses the database, specifically that the ejbStore() method is invoked, is a function of the transaction isolation parameter.
    Reply to this Reply to original

  6. EJB Caching Issues[ Go to top ]

    hi phan....
    Use of Entity Beans and Stateful Session Beans does cause unwanted overhead. To what extent will this affect performance. Also while a combination of stateless session bean and http session can be a substitute to Stateful Session Beans... When do we actually go in for a stateful session bean?
    regds
    lalitha
    Reply to this Reply to original

  7. EJB Caching Issues[ Go to top ]

    This is exactly what we do, however we use weblogic startup classes to create a singleton object within the appserver that then runs mutiple threads to sevice request for data. If you don't like this then the otehr approach is to RMI or CORBA out to a server outside the appserver. However you then have the overhead of a remote call.

    This design is used extensively and works very well, the only problem is if your cache hits more than the 1Gb size, you then run into problems with the GC cycles being too long and effecting clients connected to the app server as they time out.

    Bye
    Reply to this Reply to original

  8. EJB Caching Issues[ Go to top ]

    If the database is not being used outside of your application, you can set dbIsShared to false. This will prevent ejbLoad() from being called on every call to a remote interface method.

    Scot.
    Reply to this Reply to original

  9. EJB Caching Issues[ Go to top ]

    Andrew,
    I read your response to the "EJB Caching issue" with great interest. Can you tell me how one can use "weblogic startup classes to create a singleton object". I will appreciate if you could show me the code/steps that it takes to set up this singleton object. I am not very familiar with weblogic server.

    Best regards,
    Deepak Nautiyal
    Reply to this Reply to original

  10. EJB Caching Issues[ Go to top ]

    I too am running Weblogic (5.1) and am using a startup class to create a Singleton object that acts as a data cache. It is really quite simple. Weblogic provides for a mechanism so that classes which are specified as startup classes in the properties file will be run upon server startup. In our case, this class performs some database queries and parses the ResultSet into a series of custom classes. These classes are then bound to the context via JNDI. The application then retrieves by calling a method in a stateless session bean which does the appropriate JNDI lookup. Seems to work great but I do have one question.
    A previous reply to this thread mentioned an issue where if the cache exceeds 1 GB, server performance will suffer. Our cache is no where near that size but I could imagine it growing to 50-100 MBytes. When the objects are bound, are they serialized and written to disk? I have conducted some preliminary tests on our app and it appears to me that our cache is stored in RAM and not on disk. I ask this because I can't imagine a server which can stand to tie up 1 Gig of RAM to store a cache. (Maybe we just have whimpy servers where I work.)

    Thanks,
    Steve
    Reply to this Reply to original