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.
You can use read-only or read-mostly entity beans for data caching.
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.
There are some anomolies related to read only entity beans. I suggest, you must look into these before you consider using them.
Just making statements doesn't help. Can u point out the anomolies related to readonly entity beans in this forum??
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.
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.
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...
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?
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.
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.
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.
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.
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.
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.
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.
Can u send some pointers related on Caching.I have seen your answers in Serversdide.
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
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
There are probably some good reasons not to do it this way
but it works which is the most important thing.
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.
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.
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.
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?
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
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.