- Posted by: Hermann RANGAMANA
- Posted on: April 24 2003 09:40 EDT
In the project i'm currently working on, we have the classic scenario of accessing a most read-only from database and ... caching it for further request. So a collegue of mine proposed the following scenario :
- When we receive an upcoming request, we do a findByPrimaryKey (). If the object is found, return it, otherwise perform a direct jdbc call to the database and then create an entity bean to hold the object and return it.
So entity beans are used mainly (and exclusively) as data caching. No transcation issue, no concurrent access issue, no remote access issue, only for basic cache purpose.
What do you think of this? Is it really worth using entity beans in this case ?
Any comments welcomed
In my humble opinion, when we decided to use Entity Bean or not in an application, we have to look at the nature of the system, like you said, the transaction requirement, scalability requirement etc.
There are plenty of good articles regarding this issue on the web, and this is one of them:
Either way (JDBC or Entity Bean), we can cache the data and this issue alone should not be the "break point" of deciding what to use.
It sounds like you're trying to do the job of a container, but making a bit of a pigs ear of it.
If you "create" an entity bean you will end up causing a create statement on the database, as far as I know, doing a finder on PK will go off to the database to perform a select, although the behaviour with commit option A & B may be different. Unless you use locals you will still have the remote overheads when you access the entity bean. Maybe I'm missing something, but I don't understand why you think you'll be bypassing concurrency etc.
If you want to speed things up using a cache then don't reinvent the wheel, take a look at MVCSoft, it's very cheap, very good and will do what you guys are looking for here.
If the requirement is just about basic caching, then I dont think you will have to use an EntityBean to achieve the same.
You could use a DAO to make direct calles to database and store the required information in cache and provide the same from cache on subsequent requests.
Whether or not you have EntityBeans in your system, for this particular requirement you could use the above option with out having any dependency on Entity EJBs for getting cached data.
I dont know the complexity of your system nor containers you were using. If you are expecting thousands of simultaneous hits, then you might want to explore utilities that Robinson was suggesting. Otherwise good caching logic should do.