Hello Ravi, > 1. What would be a good place to intercept JOOQ and add similar > functionality?
jOOQ does not implement a second-level cache itself. Neither are there plans to do so. For that kind of behaviour, you will probably have to implement second-level caching yourself and hide it behind a DAO or service layer - whichever is more suitable in your architecture. This can be done with your current thread-based architecture, or with sophisticated caching products, such as JBossCache, EhCache, etc. Maybe this would be a good question for Stack Overflow? With a broader audience, there may be other input / ideas! Note, that I'm thinking about generating Spring-based DAO interfaces and implementations, which can be extended / customised. These ideas are a recent contribution by Sergey Epik, which I'm planning to integrate in the next couple of months. > 2. The other option is to add a loadByPK() method on the Tables which calls > JOOQ internally and caches the data on return. What would be the best way to > do this? Right now, this isn't possible as your methods would be overwritten at the next re-generation. I have plans to allow for preserving custom code in generated classes between generations. Maybe in the future, I'll also support velocity or another scripting language for such extensions. I guess right now, hiding these things behind a DAO layer is probably the best option. Cheers Lukas 2012/4/12 Ravindra Wankar <[email protected]>: > With our in-house ORM, we cache results of queries made using the primary > key for a table within a single thread. e.g if I fetch user a user where ID > = 100, this is cached. This ensures that a call from another part of the > code does not result in an SQL query. Since the cache stores the object, any > modifications made by a piece of code are also available to another. > > 1. What would be a good place to intercept JOOQ and add similar > functionality? > 2. The other option is to add a loadByPK() method on the Tables which calls > JOOQ internally and caches the data on return. What would be the best way to > do this? > > Thanks. > - Ravi
