Hi Weifeng, I have some questions on how you have implemented approach 2 and 3.
Approach 2: How can we cache data as hashmaps in stateless beans? Suppose I have a pool of stateless bean and hashmaps stored in one of the Stateless bean. There is not guarantee that every time container uses this Stateless bean. So my questions is how can we stored data that has application scope in EJB. I can use ServletContext but I would like to know how I could do in EJB? Approach 3: I understand that you can cache entity bean. Isn't it container load fresh data from db when you try to use even cache entity bean? I tried to find answer myself but could not get much. I'm newbie so take it lightly if questions are too obvious. Thanks Deepak -----Original Message----- From: A mailing list for Java(tm) 2 Platform, Enterprise Edition [mailto:[EMAIL PROTECTED]]On Behalf Of Jasper Fontaine Sent: Thursday, January 10, 2002 9:51 AM To: [EMAIL PROTECTED] Subject: Re: caching hi all >===== Original Message From [EMAIL PROTECTED] ===== >jasper, > >We did the similar approaches in our application. There are 3 approaches to >cache data: > >1) cache data in memory, such as in hashtables as you said. When some data >is modified, use jdbc to update database. you need to handle transactions by >yourself. > >2) cache data in memory, as in 1). When some data is modified, find the >corresponding entity beans and update them. container handles transaction. >But this approach is slower than the first one. > >3) cache data by caching all entity beans. I remember each entity bean takes >about 3KB in WebLogic, so this approach fails if you have lots of data. > >We used the second approach. We cached all data as HashMaps in some >stateless session beans. Our application is rather small, less 20K rows in >database. We deployed it on WebLogic and JBoss, it works fine. > >JMHO > >Weifeng interesting approach i think. Come to think of it, this might be the best solution to my read-mostly scenario. I will try this and perform some tests. Have you tested it with larger datasets than 20K? And how about thread-safety: won't this solution introduce a lot of synchronization problems? <[EMAIL PROTECTED]> ===== >Hi! >I'd stick with the Singleton (multiple instances can occur, but since they'd >be loaded by different clasloaders they're distinct, see >http://www.javaworld.com/javaworld/jw-01-2001/jw-0112-singleton.html). They >you could use the Observer pattern, to register some classes with your >singleton to receive events when the data in the singleton has changed and >to update the classes. > >-mw hi! Obviously Weifeng's method can be used for caching data from the DB, but the caching of objects (a connectionpool for example) is a whole different matter. I used to do this with a singleton, just as you suggest, but this won't work too good since there are multiple classloaders in an appserver/cluster. I agree with you when you say "multiple instances can occur, but since they'd be loaded by different clasloaders they're distinct", but that's against the whole point of a singleton, isn't it? if i only want 1 connection to the DB i don't want multiple singletons existing, all with 1 connection to the DB. I've just read this article about a "JNDIHashtable" (http://www.javaworld.com/javaworld/jw-07-1999/jw-07-cooltools.html) and thought this could be extended to some sort of JNDI-based singleton. Pro: server/JVM/classloader-independent storage, only one instance of the objectpool Con: maybe a drop in performance because there's more network overhead and because of the appserver might (un)marchal the data stored in the JNDI-tree. Besides, all objects in the tree have to implement Serializable. This might form a problem with complex pools that consist of nested containers.. I'll have to test this to form any more conclusions about this option. any new ideas? thanx and regards, jasper =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff J2EE-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
