Hmm, I think that the fix will be unnoticeable for Spring users. The change
of behaviour when removing the caching might have some impact on people
implementing their own ExecuteListener and relying on being able to access
the "current Connection" from the ConnectionProvider.

But as the negative effects of such a cache are worse for most users,
compared to the slight risk of regressions, I'd suggest that people being
exposed to the regression risk shall reproduce the previous behaviour by
explicitly implementing a ConnectionProvider, as you said.

Personally, I don't think many people really wanted the current behaviour.
It just happened to work for *some* Spring users.

Cheers
Lukas

2013/12/13 <[email protected]>

> I guess that not everybody are using spring, transactions and have enough
> requests to be affected. I think a note at Spring integration page will be
> enough for now - just like if you want to use jooq with Spring's
> transactions please use your own ConnectionProvider. Or you can even add it
> as SpringTransactionalConnectionProvider with no any impact for current
> users.
>
>
> On Friday, December 13, 2013 2:09:39 PM UTC+4, Lukas Eder wrote:
>
>> Thanks, guys, for investigating this. Interesting to see that
>> DataSourceConnectionProvider causes issues with some users but not with
>> others. Indeed, DataSourceConnectionProvider's caching of a connection has
>> been criticised recently and will be changed in jOOQ 3.3:
>> https://github.com/jOOQ/jOOQ/issues/2863
>>
>> I'm musing if this fix should be merged to jOOQ 3.2.2. The caching does
>> seem very unexpected.
>>
>> Cheers
>> Lukas
>>
>>
>> 2013/12/13 <[email protected]>
>>
>> Ok, I found how to fix with it. Never rely on default
>>> DataSourceConnectionProvider - it is using simple caching for connections
>>> and it is not good for transactional environment. So then I replaced
>>> ConnectionProvider on my own like this https://gist.github.com/
>>> abashev/7937310 everything back to normal.
>>>
>>> Thank you for pushing forward this project, it is really cool and
>>> useful!!
>>>
>>> On Friday, December 13, 2013 3:08:23 AM UTC+4, [email protected] wrote:
>>>>
>>>> Hm, I've replaced using with 'new DefaultDSLContext(config)' but with
>>>> the same result.
>>>>
>>>> If you not able to reproduce then maybe something wrong with my
>>>> environment - MacOS, Java 7.0_45, Spring 3.2.5, TestNG 6.8.7
>>>>
>>>> On Friday, December 13, 2013 2:14:09 AM UTC+4, Jason H wrote:
>>>>>
>>>>> Alexy,
>>>>>
>>>>> I believe we're both running into the same issue from different
>>>>> angles.  I've created a test class in org.jooq.test.spring in the
>>>>> jOOQ-codegen-maven-example tree and have been trying to recreate my
>>>>> problems there.  I reused your suggestion and switched from selectOne
>>>>> to selecting from the test class T_BOOK, but was unable to recreate
>>>>> what you were seeing.  I'll try and post a gist later.  Your situation
>>>>> may be that the using() method you're calling isn't creating a new DSL
>>>>> context each time, and is therefore running into the known thread
>>>>> safety issues.
>>>>>
>>>>> Hope that helps, I'm still plugging away on my end.
>>>>>
>>>>> Thanks,
>>>>> Jason
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Dec 12, 2013 at 4:32 PM,  <[email protected]> wrote:
>>>>> > Jason,
>>>>> >
>>>>> > There is much more simpler example for testng semantic
>>>>> >
>>>>> >     @Test(threadPoolSize = 10, invocationCount = 100)
>>>>> >     public void concurrencyForFinder() {
>>>>> >         TransactionStatus tx = transactionManager.getTransaction(new
>>>>>
>>>>> > DefaultTransactionDefinition());
>>>>> >
>>>>> >         using(config).select().from(USER_BLOCK).fetchCount();
>>>>> >
>>>>> >         transactionManager.commit(tx);
>>>>> >     }
>>>>> >
>>>>> > You could use any table there. And it is with
>>>>> DataSourceTransactionManager
>>>>> > so no any hibernate code involved. Errors are 100% reproducible.
>>>>> >
>>>>> >
>>>>> >
>>>>> > On Friday, December 13, 2013 1:22:25 AM UTC+4, Jason H wrote:
>>>>> >>
>>>>> >> Alexey,
>>>>> >>
>>>>> >> I may be misunderstanding, but I thought:
>>>>> >> tx = transactionManager.getTransaction(new
>>>>> >> DefaultTransactionDefinition());
>>>>> >>
>>>>> >> instantiated a new transaction on the connection after a commit.
>>>>> >>
>>>>> >> Anyhow, I am running into similar issues and modified the test in
>>>>> the
>>>>> >> example code.  However, the selectOne() does not run into currency
>>>>> >> issues, due to speed, so I abandoned it for the time being.
>>>>> >>
>>>>> >> I've been alternating between modifying the example code and
>>>>> modifying
>>>>> >> my own code (which is too complex to use as an example) to try and
>>>>> >> find the issue.
>>>>> >>
>>>>> >> Thanks,
>>>>> >> Jason
>>>>> >>
>>>>> >>
>>>>> >> On Thu, Dec 12, 2013 at 4:03 PM,  <[email protected]> wrote:
>>>>> >> > This is not related to H2 itself - I have the same behaviour at
>>>>> MySQL
>>>>> >> > instance. And yes it is Hibernate transaction manager because
>>>>> right now
>>>>> >> > I'm
>>>>> >> > migrating the app from Hibernate to jooq and I can't just throw
>>>>> it away.
>>>>> >> > But
>>>>> >> > I have the same errors with
>>>>> >> > org.springframework.jdbc.datasource.DataSourceTransactionManager
>>>>> so it
>>>>> >> > is
>>>>> >> > not directly involved.
>>>>> >> >
>>>>> >> > I'm not sure about Jason's comment - he has been tried to commit
>>>>> >> > transaction
>>>>> >> > one more time and got an error. So I'm not trying to commit twice
>>>>> the
>>>>> >> > same
>>>>> >> > transaction - I just have many threads with many transactions
>>>>> that try
>>>>> >> > to do
>>>>> >> > a query. Maybe you store a connection somewhere inside record and
>>>>> then
>>>>> >> > ten
>>>>> >> > processing thread complete processing and new cycle have to begin
>>>>> JOOQ
>>>>> >> > rely
>>>>> >> > on old config-connection values?
>>>>> >> >
>>>>> >> > On Friday, December 13, 2013 12:10:04 AM UTC+4, Lukas Eder wrote:
>>>>> >> >>
>>>>> >> >> Hi Alex,
>>>>> >> >>
>>>>> >> >> Thanks for the detailed report. I don't think this is a bug in
>>>>> jOOQ,
>>>>> >> >> but
>>>>> >> >> maybe it is a "documentation bug", i.e. a flaw with what is
>>>>> currently
>>>>> >> >> documented here:
>>>>> >> >>
>>>>> >> >>
>>>>> >> >> http://www.jooq.org/doc/3.2/manual/getting-started/tutorials
>>>>> /jooq-with-spring/#comment-1158280997
>>>>> >> >>
>>>>> >> >> Notice also Jason's comments on that manual page.
>>>>> >> >>
>>>>> >> >> Other possible issues that I can see:
>>>>> >> >> - You're using H2's MVCC mode, which is still somewhat
>>>>> experimental, I
>>>>> >> >> believe.
>>>>> >> >> - Is your using the Spring HibernateTransactionManager
>>>>> intentional?
>>>>> >> >>
>>>>> >> >> Cheers
>>>>> >> >> Lukas
>>>>> >> >>
>>>>> >> >>
>>>>> >> >> 2013/12/12 <[email protected]>
>>>>> >> >>>
>>>>> >> >>> Guys,
>>>>> >> >>>
>>>>> >> >>> I'm trying to jooq in a project with many concurrent web
>>>>> requests and
>>>>> >> >>> I
>>>>> >> >>> found really strange behaviour for simple finder methods. There
>>>>> is my
>>>>> >> >>> code
>>>>> >> >>> and test for testng
>>>>> >> >>>
>>>>> >> >>>  @Override
>>>>> >> >>>     public UserBlock findById(int userId, int friendId) {
>>>>> >> >>>         UserBlockRecord record = using(config).fetchOne(USER_BLOCK,
>>>>>
>>>>> >> >>> byId(userId, friendId));
>>>>> >> >>>
>>>>> >> >>>         return ((record == null) ? null :
>>>>> >> >>> record.into(UserBlock.class));
>>>>> >> >>>     }
>>>>> >> >>>
>>>>> >> >>>
>>>>> >> >>>     @Test(threadPoolSize = 10, invocationCount = 100)
>>>>> >> >>>     public void concurrencyForFinder() {
>>>>> >> >>>         new TransactionTemplate(transactionManager).execute(new
>>>>>
>>>>> >> >>> TransactionCallbackWithoutResult() {
>>>>> >> >>>             @Override
>>>>> >> >>>             protected void
>>>>> >> >>> doInTransactionWithoutResult(TransactionStatus
>>>>> >> >>> status) {
>>>>> >> >>>                 final Random random = new Random();
>>>>> >> >>>
>>>>> >> >>>                 userBlockDao.findById(random.nextInt(100),
>>>>> >> >>> random.nextInt(100));
>>>>> >> >>>             }
>>>>> >> >>>         });
>>>>> >> >>>     }
>>>>> >> >>>
>>>>> >> >>> And here is how it is crashing
>>>>> >> >>>
>>>>> >> >>>     org.jooq.exception.DataAccessException: SQL [select
>>>>> >> >>> `user_block`.`user_id`, `user_block`.`friend_id`,
>>>>> >> >>> `user_block`.`created_time`, `user_block`.`is_block` from
>>>>> `user_block`
>>>>> >> >>> where
>>>>> >> >>> (`user_block`.`user_id` = 87 and `user_block`.`friend_id` =
>>>>> 5)];
>>>>> >> >>> Connection
>>>>> >> >>> is broken: "session closed" [90067-173]
>>>>> >> >>>         at org.jooq.impl.Utils.translate(Utils.java:1158)
>>>>> >> >>>         at
>>>>> >> >>>
>>>>> >> >>> org.jooq.impl.DefaultExecuteContext.sqlException(DefaultExec
>>>>> uteContext.java:495)
>>>>> >> >>>         at org.jooq.impl.AbstractQuery.ex
>>>>> ecute(AbstractQuery.java:325)
>>>>> >> >>>         at
>>>>> >> >>>
>>>>> >> >>> org.jooq.impl.AbstractResultQuery.fetchLazy(AbstractResultQuery.java:344)
>>>>>
>>>>> >> >>>         at
>>>>> >> >>>
>>>>> >> >>> org.jooq.impl.AbstractResultQuery.fetchLazy(AbstractResultQuery.java:335)
>>>>>
>>>>> >> >>>         at org.jooq.impl.SelectImpl.fetchLazy(SelectImpl.java:1044)
>>>>>
>>>>> >> >>>         at
>>>>> >> >>> org.jooq.impl.DefaultDSLContext.fetchLazy(DefaultDSLContext.java:1778)
>>>>>
>>>>> >> >>>         at
>>>>> >> >>> org.jooq.impl.DefaultDSLContext.fetchOne(DefaultDSLContext.java:1758)
>>>>>
>>>>> >> >>>         at
>>>>> >> >>> ***********.UserBlockDaoImpl.findById(UserBlockDaoImpl.java:48)
>>>>>
>>>>> >> >>>
>>>>> >> >>> I'm using Spring to couple everything together so there is my
>>>>> xml
>>>>> >> >>>
>>>>> >> >>>     <bean id="pooledDataSource"
>>>>> >> >>> class="org.springframework.jdbc.datasource.SimpleDriverDataSource">
>>>>>
>>>>> >> >>>         <property name="driverClass" value="org.h2.Driver"/>
>>>>> >> >>>         <property name="url"
>>>>> >> >>>
>>>>> >> >>> value="jdbc:h2:mem:testdb;LOCK_TIMEOUT=30000;MVCC=true;DB_
>>>>> CLOSE_DELAY=-1;MODE=MySQL;INIT=RUNSCRIPT
>>>>> >> >>> FROM 'classpath:database/init_schema.sql';"/>
>>>>> >> >>>     </bean>
>>>>> >> >>>
>>>>> >> >>>     <bean id="dataSource"
>>>>> >> >>>
>>>>> >> >>> class="org.springframework.jdbc.datasource.TransactionAwareD
>>>>> ataSourceProxy">
>>>>> >> >>>                         <property name="targetDataSource"
>>>>> >> >>> ref="pooledDataSource" />
>>>>> >> >>>     </bean>
>>>>> >> >>>
>>>>> >> >>>     <bean id="transactionManager"
>>>>> >> >>>
>>>>> >> >>> class="org.springframework.orm.hibernate4.HibernateTransactionManager">
>>>>>
>>>>> >> >>>         <property name="sessionFactory" ref="sessionFactory" />
>>>>> >> >>>     </bean>
>>>>> >> >>>
>>>>> >> >>>     <bean id="jooqConfig" 
>>>>> >> >>> class="org.jooq.impl.DefaultConfiguration">
>>>>>
>>>>> >> >>>         <constructor-arg index="0">
>>>>> >> >>>             <bean 
>>>>> >> >>> class="org.jooq.impl.DataSourceConnectionProvider">
>>>>>
>>>>> >> >>>                 <constructor-arg ref="dataSource" />
>>>>> >> >>>             </bean>
>>>>> >> >>>         </constructor-arg>
>>>>> >> >>>         <constructor-arg index="1"><null /></constructor-arg>
>>>>> >> >>>         <constructor-arg index="2"><null /></constructor-arg>
>>>>> >> >>>         <constructor-arg index="3"><null /></constructor-arg>
>>>>> >> >>>         <constructor-arg index="4"><null /></constructor-arg>
>>>>> >> >>>         <constructor-arg index="5"><value
>>>>> >> >>> type="org.jooq.SQLDialect">MYSQL</value></constructor-arg>
>>>>> >> >>>         <constructor-arg index="6">
>>>>> >> >>>             <bean class="org.jooq.conf.Settings">
>>>>> >> >>>                 <property name="renderSchema" value="false" />
>>>>> >> >>>                 <property name="statementType"
>>>>> >> >>> value="STATIC_STATEMENT"
>>>>> >> >>> />
>>>>> >> >>>             </bean>
>>>>> >> >>>         </constructor-arg>
>>>>> >> >>>         <constructor-arg index="7"><null /></constructor-arg>
>>>>> >> >>>     </bean>
>>>>> >> >>>
>>>>> >> >>> Is it somethign wrong with my config or I faced with a bug?
>>>>> >> >>>
>>>>> >> >>> Thank you,
>>>>> >> >>> Alex.
>>>>> >> >>>
>>>>> >> >>> --
>>>>> >> >>> 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/grou
>>>>> ps/opt_out.
>>>>> >> >>
>>>>> >> >>
>>>>> >> > --
>>>>> >> > 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/groups/opt_out.
>>>>>
>>>>> >
>>>>> > --
>>>>> > 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/groups/opt_out.
>>>>>
>>>>  --
>>> 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/groups/opt_out.
>>>
>>
>>  --
> 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/groups/opt_out.
>

-- 
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/groups/opt_out.

Reply via email to