my 2 cents... don't cache financial / OLTP data, anything thats likely to change within the lifetime of a single release. Bite the bullet and load it from the database. cache things like lookup lists & static data, be very cautious with more aggressive caching without a distributing caching / invalidation mechanism. Database hits are pretty fast unless you have a *lot* of them or some long-running queries, and then you should probably re-examine your architecture and look at hitting pre-built OLAP tables instead or similar...
If you don't mind going the distributed cache route though, then you can look at stuff like EhCache or similar. I haven't looked at these but I assume they would have some sort of integrated invalidation mechanism, but not having used them I can't comment much. Has anyone else used a Java distributed cache and dealt with stale cache / invalidation issues? cheers! 2008/12/5 etzel <[EMAIL PROTECTED]> > > > > On 4 Dez., 14:06, Michael Lee <[EMAIL PROTECTED]> wrote: > > I would recommend that you would go with the simplest option B first and > > migrate to service-oriented option D. > > But it kind of feels a bit dirty having multiple applications > accessing the same data the same time. It is a bit like communication > through the database. What about caching (Hibernate 2nd Level Cache). > I would frequently have to invalidate the cache. What about > transaction. I'd had a better feeling if there would be only one > client that accesses the data. > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
