My initial reaction to this was of highly skeptical, as I don't see
how adding layers and layers of adapters helps performance, which is
crucial to the very purpose of Caching being effective.
But the PR mentions interesting things; if indeed people want to use
cloud service abstractions for "gene
Someone just opened a PR to add support for Spring Cache as a second-level
cache provider[1]. They implemented this by adding a new Hibernate module
`hibernate-spring-cache` that essentially wraps Spring Cache as a JCache
(apparently Spring Cache does not implement the JCache contracts).
Part of
As I understand it, the MySQL driver/db does not support a fetch size. It
supports a binary choice between (1) pull all results into client memory
or (2) stream and buffer, but without any control over the sizing of that
buffering. If I am incorrect in that understanding then the rest here
maybe
On 21 November 2016 at 18:17, Steve Ebersole wrote:
> I had a discussion about this with Vlad on the PR and privately on HipChat.
>
> I personally am -1 on this as well. As you say Sanne the problem is "if you
> all think Hibernate should be able to figure this out automatically"... You
> would
I had a discussion about this with Vlad on the PR and privately on HipChat.
I personally am -1 on this as well. As you say Sanne the problem is "if
you all think Hibernate should be able to figure this out
automatically"... You would never be able to figure this out across all
situations.
On M
Hi Vlad,
I'm not sure if we should set the fetch size automatically, especially
not globally. Could we not use the API wisely to encourage people to
provide an estimate of a reasonable size, which will be different on
each query?
I'm aware that MySQL requires this strange value to avoid pre-loadin
SQL 92, 93 and 99 (i have not checked 2003) all limit order-by to only be
allowable in the root query.
Unfortunately the current HQL grammar allows subqueries to be ordered. So
I wanted to start a discussion of whether we want to support this as we
transition to SQM and 6.0. The real problem wit
The only thing related to transaction handling was the way connection are
released. Now, we are using AFTER_TRANSACTION instead of ON_CLOSE for
resource local ones.
But that should not impact your test, I guess.
Vlad
On Mon, Nov 21, 2016 at 4:44 PM, Steve Ebersole wrote:
> The change in excepti
The change in exception type is new to 5.2 (merging HEM into core). IIRC
you did not "see failures in hibernate-infinispan tests" because we had
those disabled due to their ongoing intermittent failures.
On Mon, Nov 21, 2016 at 5:46 AM Radim Vansa wrote:
> Aha, that explains why the test take
Aha, that explains why the test take much longer. I was just about to
look this up. I'll see if I can shorten this for tests where we expect
such situations.
Nevertheless, the test seems to be failing because it used to throw
org.hibernate. PessimisticLockException and now it is throwing
javax
Hi Radim,
I was wondering the same; I am not sure yet if it's related, but
noticed that the JDBC connection URL changed from
jdbc:h2:mem:db1;DB_CLOSE_DELAY=-1
to
jdbc:h2:mem:db1;DB_CLOSE_DELAY=-1;LOCK_TIMEOUT=1
I'm running the testsuite now reverting that change locally, but I
can't say ye
Actually those tests just failed, so that's not it.
On 21 November 2016 at 11:15, Sanne Grinovero wrote:
> Hi Radim,
> I was wondering the same; I am not sure yet if it's related, but
> noticed that the JDBC connection URL changed from
>
> jdbc:h2:mem:db1;DB_CLOSE_DELAY=-1
>
> to
>
> jdbc:h2:mem
Hi,
I am investigating the failures in hibernate-infinispan testsuite and
I've found that [1] is failing as this uses two threads that both do
1. load entity
2. delete entity
3. flush session
4. commit tx
on the same entity. There is a synchronization blocking the commit until
both threads flu
13 matches
Mail list logo
