Hi Marco,
>Yes, current one used BMP entity beans (poorly implemented....)
>One design pattern suggested was the weblogic 'read-mostly' design pattern.
>But that data needs ONLY to be read by my application, so using an EJB for reading data is a little >expense.
Agreed.
>I can use Session bean (stateful), but what about updating it? the database is updated from another >application, so in my application how should i detect it? i should find a way to tell to my application 'ok, >now re-read the data in the database..
You will either have to use a �pull� or �push� strategy here.
The push strategy being that the application updating the persistent store should notify your J2EE component that the underlying data has changed. I worked on a project where we did just that. The underlying CORBA based system notified via a publish-n-subscribe messaging system that the persistent store had changed. We used this strategy due to the number of distributed J2EE components, that had to be notified.
Or you can have a point-2-point interface with the underlying application, to obtain updated status signals.
The �pull� model is the simpler of the two strategies. Basically, your J2EE component needs to poll the persistent store to check for updated status. You can use the �timer� java class to set appropriate sleep times.
You can incorporate either of these methods with the �Evictor� pattern for your chache if you wish or just use it in isolation.
> Business/Domain Java Object. Do u have any example on that?
Domain objects are just objects holding the required information for a given context ie. International services In your situation, this would form the basis of your cache. Whatever you needed to cache. You then need to turn this into (transfer) value objects and pass them to your web tier to form the second stage cache.
Take a look at:
http://www.jvalue.org/You would normally use the domain objects in conjunction with DAO to retrieve the information from your persistent data store, if this is how you wanted to retrieve your data rather than using entity beans.
> Basically have the cache (array of services for the different coutries) sitting on your JSP/Servlet engine > as a java object (singleton). How it gets it from the Business tier (ejb container is up to you). Allow the
> evictor object to refresh this cache at predetermined values. A cache manager Servlet could be used to
> retrieve from the cache.
> and thus i have to provide my servlet a method that is called ONLY when i want to refresh the cache,
> right?
Not necesseraly, it is the job of the cache manager (Evictor pattern) to make sure that the cache is always in a most recent state.
>What about using JDO?
If the JDO libraries are available then you can use them instead of JDBC. It is another form of the JDBC API�s. JDO abstracts some of the underlying symantics of the JDBC API�s.
> If i retrieve all the objects with a query within the same transaction (initiated when the servlet is
> initialized, and ended when the servlet 'exits'), if i am correct every change in the database will be
> reflected in the objects retrieved by the query. Is that correct?
I�ll try to describe the scenario with a simplistic diagram.
Jsp -> servlet1 -> chache manager in web tier -> chache manager in ejb tier -> persistent store
The jsp and servlet1 are your business logic.
The chache manager in the ejb tier can be either an entity bean (bmp or cmp) or a session bean (stateful) with smarts built into it to keep itself updated. Push, pull model, DAO, JDO or JDBC with or without the evictor pattern. If the stateful bean is used then it should be created by the session fa�ade in your ejb tier. As all requests from your web tier should go through this session fa�ade.
You can then create a second cache manager in your web tier if you so wish for performance reasons. Make the cache as a singleton (domain) java object. The second cache manager should �ping� the first cache for updated status. This is using the pull model. If the first cache has changed then the second cache can update itself.
Your business servlet should not be aware of this.
Because you do not know which language service will be required at runtime I would suggest that all the services be cached.
This was a bit of explaining, again I hope it makes sense. Not knowing all the facts makes this a best guess for me :)
Cheers Luie
Yahoo! Messenger for SMS - Now send & receive IMs on your mobile via SMS
