create primary keys for your data, create an identity object to represent legacy data, create a hashmap or cache interface and use either LRU's or Softly referenced caching. Pretty straight forward. Logic would be "select primary keys + lastModified" if changed or not found, create, else pull from cache.
-------- Jacob Hookom Senior Programmer/Analyst McKesson Medical Surgical Golden Valley, MN -----Original Message----- From: Erik Price [mailto:[EMAIL PROTECTED] Sent: Friday, June 20, 2003 3:41 PM To: Struts Users Mailing List Subject: [OT] caching strategy There is an internal app that is used at my company and I am tossing around the idea of investing a little time and energy into making a simple web front-end for accessing data in this app. However, it does not use a traditional database with JDBC connections, so I could not maintain a connection pool with which to fetch app data. I am thinking that I could use a session bean to query the app (I have already written a codebase in Java to fetch the app's data from queries), but things like list boxes would need to be populated in JSP/HTML forms from semi-current data. This is the sort of thing that I would prefer to cache rather than constantly be querying the application whenever someone requests a new HTML/JSP. In short, when building a J2EE app to access legacy applications, what is a good strategy for maintaining an app-level cache? Thanks for your opinions. Erik --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
