Hi Gian, 2015-03-31 16:59 GMT+02:00 Gian <[email protected]>:
> Hi Lukas, > > Thank you for your suggestions these are very useful indeed: the first > mapping alternative already reads much fluently; > the second is even fancier and I'm tempted by it. > > I've just tried both and (of course) they work ;) What keeps me of using > the second option immediately are the possible > less descriptive (column) names coming from the database tables... > Yes, I understand... One way to work around that would be to make use of JPA @Column annotations, which are also supported by jOOQ's DefaultRecordMapper... Concerning the thread safety issue, I will have to study how to best do > this in the bigger picture of the layer talking to > jOOQ. How do jOOQ users generally handle this? > In general, you: - Should not cache Routine or Query objects - May cache Routine or Query objects in thread-safe object pools, although I doubt that really helps performance - May cache Configuration, DSLContext, and related objects Specifically, the Configuration might be interesting to "cache" (or rather, configure) as a singleton, e.g. through dependency injection via Spring or JavaEE CDI. When you use a DataSource, and thus jOOQ's DataSourceConnectionProvider, threadsafe access to the JDBC Connection and the transaction model is already implemented by that DataSource - jOOQ won't add state there. An example jOOQ+Spring setup can be seen here: - http://www.jooq.org/doc/latest/manual/getting-started/tutorials/jooq-with-spring/ - https://github.com/jOOQ/jOOQ/tree/master/jOOQ-examples/jOOQ-spring-example jOOQ + JavaEE can be seen here: - https://github.com/jOOQ/jOOQ/tree/master/jOOQ-examples/jOOQ-javaee-example -- 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.
