How do I create a cache object?

[jsimone]

I have an application using JBoss 3.0.4 implementing a session facade pattern in which all our entity beans are referenced by session bean methods. Our tomcat web client calls only on the session bean methods.

Problem is, I am fetching and computing the same set of data over and over again for each user that logs into the system. For example, we have a conference enrollment application. It has a schedule with fixed dates, and times. The dates and times never change, yet for each user that logs on, we have to go to the session layer and then the entity layer to make the calls necessary to return the conference schedule of dates and times.

When several hundred users log in, the overhead of computing dates and times is so high - for EACH USER --that the system just stops with a huge backlog of SQL queries to the DB and eventually 1 of two things happens: 1) the DB is overwhelmed and blows through some storage limit, or 2) the system response drops to 0 until enough frustrated users go away thus allowing the system to recover and process the remaining queries.

How can I make a cache object, with a couple of HashMaps in it, that will be created and filled once and that the session beans can read data from? Is this a stateful bean? I didn't think so, because there is no conversational state and the state never changes. Maybe I am wrong.

Any help is kindly appreciated.

Joe

[minamoto]

The read-only flag could be set to your entity beans in jboss.xml. The read-only entities doesn't load same data over and over again because the server doesn't have to synchronize them with db records at the beginning of every transaction.

Or you could control entity cache with commit options in jboss.xml. Commit option A may be used if you assume the database records are not modified by anybody other than your jboss server. The entities are cashed and maintained between transactions.

Besides, commit option D plus read-only flag is also useful for read-mostly entities. They are treated as read-only but the cache is flushed periodically.

I don't know about distributed cache between servers nor clustering discussions related to commit options.

Miki

[jsimone]

Miki,

All of our entity beans have the read-only attribute and we are using commit option A. Doing so made performance go from very poor to better, but still unacceptable.

We need a way of caching data for all users that is used repeatedly and is common to all users. Fetching it once from the beans and putting in HashMap for rapid access is what we want to do. How do we do it?

Joe

[dancornell]

Have you looked at creating a simple JMX MBean that would create the objects you want to cache and just stuff them into the JNDI context? Then the EJBs (session or entity) could pull them down.

We use the custom MBeans to load all of the DAOs for our applications and save them on the JNDI tree Then our Session beans load the DAOs based on entries in their java:/comp/env/ configuration information. Not the exact problem you all are trying to solve, but the same solution should work in both cases.

That seems to be the cleanest way we have found to make common objects available to the whole system.

[jsimone]

Thanks Dan. That sounds like a good suggestion and I am willing to go for it. I am at a point of desperation, looking to improve system throughput. Do you have any sample code that you code share for how I would go about doing so.

I know nothing about JMX or how to configure JBoss for such a caching scheme.

Many thanks,
Joe

[damon311]

I'm new to EJB's so someone correct me if I'm wrong, but you could try using the Business Delegate pattern where vanilla Java classes are used as a Facade to your Session Facade. All client calls go through the Delegate where you could add logic to cache your objects in a HashMap, etc. Once the data is cached on the client you never have to invoke the session bean again.

[hunterhillegas]

What about having one of your controller servlets get and store the stuff in the application scope of your Web App each time the app is deployed (or on some timed interval)?

Then the calls to get that data never leave the Web container except for when you specify.

[dancornell]

If you have the for-pay documentation, they have an example that should fit your needs almost exactly. It is in Chapter 2: The JMX Microkernel and is in the secion on "Writing a JBoss MBean Service" They create a JNDIMapMBean that they use to bind a HashMap to the JNDI context, and they take it through a couple of iterations where they show different ways to solve it. In my copy of the docs, the discussion starts around page 69 but the copy I'm using is maybe one minor revision out of date.

If you don't have the for-pay documentation, first of all I would recommend buying a copy because it is pretty good. The 2.4.x free documentation also has an example like this:
<http://www.jboss.org/online-manual/HTML/ch11s26.html> The MBean stuff (JBoss-specific interfaces) might have changed slightly, but the basic idea is the same.

[dancornell]

Hrm... posted this a couple of minutes ago, but it does not seem to have shown up yet.

--------------------------------------

If you have the for-pay documentation, they have an example that should fit your needs almost exactly. It is in Chapter 2: The JMX Microkernel and is in the secion on "Writing a JBoss MBean Service" They create a JNDIMapMBean that they use to bind a HashMap to the JNDI context, and they take it through a couple of iterations where they show different ways to solve it. In my copy of the docs, the discussion starts around page 69 but the copy I'm using is maybe one minor revision out of date.

If you don't have the for-pay documentation, first of all I would recommend buying a copy because it is pretty good. The 2.4.x free documentation also has an example like this:
<http://www.jboss.org/online-manual/HTML/ch11s26.html> The MBean stuff (JBoss-specific interfaces) might have changed slightly, but the basic idea is the same.

[jsimone]

Dan,

Yes, I have the for-pay docs and I do see the section on making an MBean service. I will investigate.

Thanks for pointing this out. It is appreciated.

Kind regards,
Joe