I plan to use session beans as front-ends to load and store objects from and to a RDMBS. Basically, instead of using session beans to wrap entity beans, I would like to use session beans to wrap "database" objects.
What is the recommended way to cache the loaded objects? For load operations, I would like to hit the database server as rarely as possible.
I do not plan to use entity beans.
Why not use Entity Beans? (unless your caching schema is drmatically different from what is being offered by your EJB container - in which case you probably do not need session beans or EJB container - just implement your caching logic and database accesses yourself).
To me, the overhead of entity bean is too heavy that even after we do some optimization like using session bean to wrap the entity bean and use isModified() method(in weblogic) to limit the database calls, we still get too many accesses to the DB. Using a session bean with proper caching seems to be a little bit difficult to program but we only make DB calls when it's necessary. Anybody can have some idea that how can we get rid of excessive DB access when using entity bean?
Well, Entity beans are a pain to use and quite inefficient because more often than not, they hit the database server more than necessary.
Did you specify the level of transaction isolation? The number of times that an entity accesses the database, specifically that the ejbStore() method is invoked, is a function of the transaction isolation parameter.
Use of Entity Beans and Stateful Session Beans does cause unwanted overhead. To what extent will this affect performance. Also while a combination of stateless session bean and http session can be a substitute to Stateful Session Beans... When do we actually go in for a stateful session bean?
This is exactly what we do, however we use weblogic startup classes to create a singleton object within the appserver that then runs mutiple threads to sevice request for data. If you don't like this then the otehr approach is to RMI or CORBA out to a server outside the appserver. However you then have the overhead of a remote call.
This design is used extensively and works very well, the only problem is if your cache hits more than the 1Gb size, you then run into problems with the GC cycles being too long and effecting clients connected to the app server as they time out.
If the database is not being used outside of your application, you can set dbIsShared to false. This will prevent ejbLoad() from being called on every call to a remote interface method.
I read your response to the "EJB Caching issue" with great interest. Can you tell me how one can use "weblogic startup classes to create a singleton object". I will appreciate if you could show me the code/steps that it takes to set up this singleton object. I am not very familiar with weblogic server.
I too am running Weblogic (5.1) and am using a startup class to create a Singleton object that acts as a data cache. It is really quite simple. Weblogic provides for a mechanism so that classes which are specified as startup classes in the properties file will be run upon server startup. In our case, this class performs some database queries and parses the ResultSet into a series of custom classes. These classes are then bound to the context via JNDI. The application then retrieves by calling a method in a stateless session bean which does the appropriate JNDI lookup. Seems to work great but I do have one question.
A previous reply to this thread mentioned an issue where if the cache exceeds 1 GB, server performance will suffer. Our cache is no where near that size but I could imagine it growing to 50-100 MBytes. When the objects are bound, are they serialized and written to disk? I have conducted some preliminary tests on our app and it appears to me that our cache is stored in RAM and not on disk. I ask this because I can't imagine a server which can stand to tie up 1 Gig of RAM to store a cache. (Maybe we just have whimpy servers where I work.)