Hi Lukas, thanks for the information, instead of the connection i am now passing the configuration to the ResultCache
configuration.set((VisitListenerProvider) () -> new CacheVisitListener()); DSL.using(new MockConnection(new ResultCache(configuration)),SQLDialect.MYSQL); But when the ResultCache executes the sql the CacheVisitListener is not called. Regards, Sheldon On Thu, Aug 13, 2015 at 5:28 PM, Lukas Eder <[email protected]> wrote: > Hello Sheldon, > > 2015-08-11 19:00 GMT+02:00 Sheldon D'Souza <[email protected]>: > >> Hi Lukas, >> >> The issue is on my side, and i need some advice on how to resolve it. I >> am currently using Jooq with Dropwizard. >> >> So the jooq configuration is created at app launch and then injected into >> my services, so the configuration is global across the app. >> >> Now introducing the caching layer i have to include MockDataProvider >> >> *Original jooq connection* >> >> DSLContext create = DSL.using(configuration) >> > > That's fine. > > >> *Jooq with caching* >> >> configuration.set(new DefaultVisitListenerProvider(new >> CacheVisitListener())); >> > > Note, though, if you have a single global Configuration, you must not call > any setters on it. You may, however, call derive() to create a new > Configuration from your global one. > > That means that your CacheVisitListener must not have any (non-global) > state. You're initialising it only once for all configuration access. What > I meant was something like: > > configuration.set((VisitListenerProvider) () -> new CacheVisitListener()); > > > This means that while the VisitListenerProvider is shared across all > configuration accesses, the CacheVisitListener is created afresh for every > query. > > configuration.set(new MockConnection(new >> ResultCache(configuration.connectionProvider().acquire()))); >> > > You should never call acquire() yourself, because every call to acquire > must be matched with a call to release(), once the query has executed. It's > better for your ResultCache to simply know the Configuration or the > ConnectionProvider, and possibly acquire a connection on the fly. > > >> return DSL.using(configuration); >> >> Now since the configuration is global, i think because of the >> MockConnection object whenever i insert an UpdatableRecord the primary key >> id is null. As a result my test cases are failing. >> > > Unfortunately, I cannot comment on that from the description I've seen so > far. > > >> How do i overcome this issue? is there a way for me to create a new >> connection from the original one and is that a good idea? >> > > I don't think you're on track here. jOOQ makes the assumption that > connection management has been taken care of externally. I.e. by your > transaction provider, container, Spring, etc. jOOQ will never explicitly > create connections or have a need for creating connections. Also, note that > a JDBC connection models a session from your Java client with your > database. Sessions are mutually independent from one another, and you > cannot access data inserted in one session from another session directly. > > Although, again, I'm not sure what made you think that connection handling > is causing the null primary key issue - I'd need to see more code, perhaps. > > I hope this helped, so far. If you have additional questions, just let me > know > Cheers, > Lukas > > -- > You received this message because you are subscribed to a topic in the > Google Groups "jOOQ User Group" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/jooq-user/xSjrvnmcDHw/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
