with ejb -- look at commit option D with a 24 hour timeout. This will give you 1 copy in memory. You may want to set it read-only also if it is really read only. There may be a way to get more than one copy using a multi-instance synchronization interceptory, I'm not sure.
Without ejb -- write an mbean to fetch and serve (copies of) the data structure. Get the data structure either by having the mbean bind it in jndi or (I think preferably) expose it as an mbean attribute and read it through the mbean server. You will have to make sure your mbean is thread safe. This will result in 1 copy with multi-threaded read. Use the mbean timer service or the jboss scheduler mbean to refresh it at a configurable interval. You mean our errors are less cryptic than theirs;-)?? Did they mean to name their package nevermind? david jencks On 2002.04.07 21:25:11 -0400 Jeff Schnitzer wrote: > Hi! I'm trying to figure out a caching strategy for a fairly simple > tree structure. The tree will be very heavily used, there are > relatively few nodes, they change only rarely, and transactional > behavior really isn't necessary. Some sort of cache which updates once > per day would be ideal. > > The basic data structure is a CMR entity bean with a one-to-many > relationship with itself. > > What is the best way to implement such a cache? > > Thought #1) Do relationships get cached along with persistent fields? > Using commit option B seems like a fairly reasonable way to get the > behavior I want - if the relationships are cached as well. Cache > invalidation is an issue, but I can probably use the Seppuku pattern to > take care of this. Or maybe setting a time-out will do the trick? > > Thought #2) Create a BMP bean which represents the relationship between > a parent and its children (as data objects), and make it read-only with > a time-out. Of course, it would load itself by grabbing the underlying > entity and calling its getChildren() method. > > Thought #3) Cache this outside the EJB system. This is a perfectly > acceptable alternative, and the one I am leaning towards. Just have a > Java object with a timer task that refreshes the entire tree once a day, > and put this object in the servlet application scope. This way I can > have a multithreaded cache and be guaranteed that there is only one > instance of it in memory. Actually, this is something I wonder about: > For #1 and #2, I would end up with several instances of the same cached > object in memory, right? > > Thanks for any advice. > > Jeff Schnitzer > [EMAIL PROTECTED] > > BTW, as an aside, I am in the midst of switching from Orion to JBoss > because I am finally fed up with errors like this: > > C:\java\orion>java -jar orion.jar > Auto-deploying similarity-ejb.jar (New server version detected)... > java.lang.NullPointerException > at com.evermind._eh._dyc(.:109) > at com.evermind._fc._izd(.:198) > at com.evermind._fc._de(.:63) > at com.evermind._fqb._de(.:30) > at com.evermind._eq._aa(.:280) > at com.evermind._ed._aa(.:270) > at com.evermind._ai._kmd(.:526) > at com.evermind._aj._kmd(.:287) > at com.evermind._aj._vxb(.:119) > at com.evermind.server.ApplicationServer._sxc(.:1308) > at com.evermind.server.ApplicationServer._ige(.:1265) > at com.evermind.server.ApplicationServer._vxb(.:1003) > at com.evermind._cxb.run(.:89) > at java.lang.Thread.run(Thread.java:536) > at com.evermind._bt.run(.:47) > > > _______________________________________________ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user > > _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
