tag:blogger.com,1999:blog-12168038.post2336228446972197715..comments2008-12-05T09:30:01.893+05:30Vinod Singhhttp://www.blogger.com/profile/14429571106836951918noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-12168038.post-79961307021719975462008-12-05T09:30:01.893+05:302008-12-05T09:30:01.893+05:30Mathew,<BR/><BR/>Yes, your observations are valid and I am aware of. This post just demonstrates the concept and far form being used as it is in production system. Besides the 'get' one has to handle 'update' and 'delete' functionality as well, so that cache is always in sync with database.Vinod Singhhttp://www.blogger.com/profile/14429571106836951918noreply@blogger.comtag:blogger.com,1999:blog-12168038.post-56888107377342825492008-12-05T04:48:03.112+05:302008-12-05T04:48:03.112+05:30Thanks for taking the time to write this post!<BR/><BR/>Your use of only the first parameter in the method call (in CacheProxy, line 24), has a bug if you wrap a method that takes 2 or more parameters.<BR/><BR/>As an example, let's try to cache a new method whose object has a composite key, getComposite(int key1, int key2).<BR/><BR/>getComposite(1, 1) will fetch (1, 1), cache the result and associate it to new Integer(1).<BR/><BR/>If you subsequently call getComposite(1, 2), it will incorrectly return (1, 1) because the first argument matched your cache backing store.<BR/><BR/>You could serialize the argument array and using that byte array as the key, or something else that looks at the argument list comprehensively to address this issue.Matthew McEachenhttp://matthew.mceachen.usnoreply@blogger.com