But are they not recommended when you read data which doesn't change.For eg when you use Read-only Entity Beans for Caching.Or is it there is too much overhead when using an Entity Bean for this purpose.
They are actually recommended for caching data that doesn�t change very often. As you already know the problem with caching is the stale data (when the data in db changes and gets out of sync with the cache), but with this strategy weblogic allow refreshing the cache after a specified interval of time. It also allows invalidating the cache programmatically. As for performances or overhead, nothing like this it works very well and the container is capable of caching a large number of ejbs without affecting the performances.
The huge drawback of this approach is that this is a weblogic specific solution and it won�t work if the beans get deploy on
JBoss for example. Another problem is that this solution is neither intuitive nor standard and requires weblogic experience. But again it works and performs really well, it is also very easy to implement or maintain and it really makes me sometimes to just forget about the j2ee crap and care more about what the container can do for me. This is actually the point I try to make with entity ejbs: use only standard j2ee feature/patterns/recommendations and you are very closed to failure; screw them, learn more about your container capabilities and you might be very successful. Finally I just want to remind you that j2ee made a lot of great promises a while ago after releasing ejb 1, they made even greater promises after releasing ejb 2, but at the end of the day you might notice that they are kind of forgetful ...
Regards.