Well the most basic thing you could do is maintain some sort of Collection of already found objects. Suppose you have the objects User and Item. You could keep two Maps which hold the alread found objects. The idea could be that when you call some CRUD business method on either of these object types, it is the cache you go to first, if they are not there then its the DB you go to.
As I say this is very simple. You would have to code such issues as the cache becoming invalid - what happens for example if some other process deletes an object from the DB currently resident in your cache? You have think of what you do to stop the cache growing too big - perhaps have a defined limit of the number of entries possible in your cached Maps and push one out to put a new one in when you get to the limit. You would need to think carefully how you decide which object gets bumped out of the cache, otherwise this could make you cache more of a drain on performance rather than an aid. Your cache would not work in a cluster - so couldn't be used in a
J2EE app (writing a clusterable cache is hard work). You might also have to decide at what point your cache commits objects to the DB - if it commits every object you update or insert straight away.
All this, since it is sort of "infrastructure" code, is usually best implemented by reusing an existing caching framework.
[ March 17, 2005: Message edited by: Paul Sturrock ]