istory issue :).
>
> From what I can see, GitLab doesn't invest much in Gitter either so I
> wonder if it's gonna be viable in the long term.
>
> I suppose we'll see.
>
--
Radim Vansa
JBoss Performance Team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
f they were optional, that would do but they are not and you always
>>> need
>>>>> 2
>>>>>> clicks to share (e.g. go to the right stream, then either choose a
>>> topic
>>>>> or
>>>>>> create new topic), whereas
eadthedocs.io/en/1.7.1/prod-multiple-organizations.html
>
> On 05/18/2018 02:57 AM, Radim Vansa wrote:
>> Just out of curiosity, when choosing a replacement for HipChat, have you
>> considered Zulip?
>>
>> Infinispan uses that for about a month now and besides being too
&
Ignore me, panicked too quickly... the dot is added there in 5.1 as well.
On 05/18/2018 09:37 AM, Radim Vansa wrote:
> One thing I've stumbled upon: it seems that RegionFactory should call
> its method qualify(String regionName) to produce the prefixed region
> name. Followi
y.name now...
Radim
On 05/18/2018 09:02 AM, Radim Vansa wrote:
> On 05/18/2018 02:54 AM, Gail Badner wrote:
>>
>>
>> On Thu, May 17, 2018 at 5:24 PM, Gail Badner > <mailto:gbad...@redhat.com>> wrote:
>>
>> I see that HHH-11356 removed prefixes fro
>>
>>>> I think (1) is the only one that is concerning. Though TBH for myself
>>>> personally, I do not think registering is a big deal.
>>>>
>>>> Unless I hear otherwise, I plan on asking them to proceed with our
>>>> migration to Stride.
>>>> ___
>>>> hibernate-dev mailing list
>>>> hibernate-dev@lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> ___
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
Radim Vansa
JBoss Performance Team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
it as confirmed that RegionFactory is supposed to do this.
Created https://issues.jboss.org/browse/ISPN-9174
R.
>
> On Thu, May 17, 2018 at 4:55 AM, Sanne Grinovero
> mailto:sa...@hibernate.org>> wrote:
>
> On 17 May 2018 at 12:09, Radim Vansa &l
mpsRegion
>>> which already exists
>>>
>>> Entity region names are not being prefixed either.
>>>
>>> Should they be prefixed by Hibernate or by the RegionFactory?
>>>
>>> Regards,
>>> Gail
>>>
>>> [1]
>>> https://github.com/
t; "truth of the system". This in in fact exactly the principle that the
> collection cache works - any changes to that collection simply
> invalidate (evict) the data from the cache.
When you simply evict a piece of data from the cache you can't be sure
that tha
I am really grateful that in 5.3 you've provided the
CacheTransactionSynchronization that will help us boost (1) even further
by allowing us to execute all operations in parallel. And it's good that
you've made the SPI more expressive with the intent; there'll be a bunch
of T
hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
Radim Vansa
JBoss Performance Team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
efore Infinispan provides native implementation to 5.3/6.0 SPIs, JCache
is a good way to bridge the gap. So if you're setting up a matrix
testing, adding Infinispan JCache provider would give us some confidence
that we can recommend that bridge in the meantime.
R.
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
Radim Vansa
JBoss Performance Team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
lly, even with multiple versions of
> OGM, so I'd hope that we can design the models of each task we'll need
> as Protobuf Entities.
I hope you won't end up with OGM generating javascript to be run on the
server :)
Radim
>
> Fabio, do you want to start working on such a
ted in local transactions.
>
> What do you think about it?
> Can I open a Jira issue?
>
> Fabio
>
--
Radim Vansa
JBoss Performance Team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
; > At some point we are professional developers and should
>>> be able
>>> > to do the non-silly things ;)
>>> >
>>> > And as far as your "register the thing twice" worry...
>>> > rhetorically, what stops them from calling:
>>> >
>>> > reg.register( "abc", MySync.INSTANCE )
>>> > reg.register( "123", MySync.INSTANCE )
>>> >
>>> > Nothing.
>>> >
>>> >
>>> > I'd rather expose a single consistent way: having to
>>> make up
>>> > an id
>>> > doesn't seem too inconvenient considering it's an SPI.
>>> >
>>> >
>>> > Well, again, I don't see how KeyableSynchronization is a
>>> > "inconsistent" approach. In fact out of the 2, it is my
>>> preferance.
>>> >
>>>
>>> --
>>> Registered in England and Wales under Company Registration No.
>>> 03798903
>>> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
>>>
>> --
>> Registered in England and Wales under Company Registration No. 03798903
>> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
--
Radim Vansa
JBoss Performance Team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
the new methods in addition to the existing method for
> people not interested in looking things up.
>
> thanks,
> Sanne
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
Radim Vansa
JBoss Performance Team
those 100 ms add up and with
over thousand of tests (for various configurations), this could be
minutes anyway.
Q: is there any infrastructure in testsuite to hook into the DB, assert
that it's waiting in lock and let the thread time out if everything is
as expected?
Radim
--
Radim Va
Hi,
seems something went wrong with HHH-11083 integration and I've broken
the nightly builds.
Fix is in [1], please integrate asap.
Radim
[1] https://github.com/hibernate/hibernate-orm/pull/1647
--
Radim Vansa
JBoss Performance
king related changes please let us know :)
>
> Thanks,
> Sanne
>
>
> On 21 November 2016 at 10:04, Radim Vansa wrote:
>> Hi,
>>
>> I am investigating the failures in hibernate-infinispan testsuite and
>> I've found that [1] is failing as this uses two thread
ating the lock acquisition to the commit instead
of flush? The test works on 5.0.10.
Radim
[1]
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/test/java/org/hibernate/test/cache/infinispan/functional/TombstoneTest.java#L37
--
Radim Vansa
JBoss Performance
improvements
>
> You think that's enough? It's a though one, as I want to be clear
> about the limitations but w/o scaring people off by repeating
> limitations too many times.
> There are also various big highlighted baloons mentioning:
>
> "
> Caution
> The
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
Radim Vansa
JBoss Performance Team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
ment).
Radim
> _______
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
Radim Vansa
JBoss Performance Team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
e module and move it from v2 to v3
>>>>>>>>
>>>>>>> Please don't do that.
>>>>>>>
>>>>>>> I'm pretty sure users will need to test Ehcache 3 before going live
>>>>>> and it
>>>>>>> shouldn't be tied to an Hibernate upgrade. Cache is a very sensible
>>>>>> subject
>>>>>>> and I'm pretty sure moving to Ehcache 3 will come with its
>>>>>> challenges. We
>>>>>>> should at least have 1 or 2 versions allowing both Ehcache 2 and 3.
>>>>>>>
>>>>>>> Moreover, last time I checked, there was no Jgroups replication yet
>>>>>> in
>>>>>>> Ehcache 3 (or it's not documented).
>>>>>>>
>>>>>>> --
>>>>>>> Guillaume
>>>>>>> ___
>>>>>>> hibernate-dev mailing list
>>>>>>> hibernate-dev@lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>
>>>>>> ___
>>>>>> hibernate-dev mailing list
>>>>>> hibernate-dev@lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
Radim Vansa
JBoss Performance Team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
s and whether we consider it a
>>> “breaking change” in a 5.x series
>>>
>>> == Doc and pointers
>>>
>>> As I said, Louis know Ehcache well but needs some input to step into the
>>> magic world of second level caching in Hibernate ORM. Thing
om/hibernate/hibernate-orm/commit/cbdab9d87f05b4255c7930a32fe995f87f0f3e0b
>
> For Infinispan, I think it's better if you can investigate if this is
> an issue or if the change does not break anything either (all
> Infinispan tests ran fine, so hopefully this should not be the case).
>
> Thanks,
> Vlad
&g
On 04/06/2016 11:58 AM, Radim Vansa wrote:
> On 04/05/2016 04:13 PM, Vlad Mihalcea wrote:
>> Hi,
>>
>> I'd definitely fix it for the refresh operation, which does an implicit
>> cache eviction too.
>> In this case, the proposed PR solution is fine since it si
hat might not
>>> perform very well in a distributed-cache scenario.
>>>
>>> Ideally, lock entries would be stored separately than actual cached value
>>> entries, and this problem would be fixed in a much cleaner fashion.
>> I'd leave th
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> ___
> h
On 01/25/2016 11:48 AM, Radim Vansa wrote:
> On 01/22/2016 05:26 PM, Steve Ebersole wrote:
>> On Fri, Jan 22, 2016 at 9:30 AM Radim Vansa > <mailto:rva...@redhat.com>> wrote:
>>
>> On 01/22/2016 03:11 PM, Steve Ebersole wrote:
>> > O
strategy-work/
>
> For sync: TRANSACTIONAL
>
> http://vladmihalcea.com/2015/06/01/how-does-hibernate-transactional-cacheconcurrencystrategy-work/
>
> Only the region strategy differs since it's not Ehcache, but
> everything else is from Hibernate API.
>
> Vlad
>
On 01/22/2016 05:26 PM, Steve Ebersole wrote:
> On Fri, Jan 22, 2016 at 9:30 AM Radim Vansa <mailto:rva...@redhat.com>> wrote:
>
> On 01/22/2016 03:11 PM, Steve Ebersole wrote:
> > On Fri, Jan 22, 2016 at 7:21 AM Radim Vansa <mailto:rva...@redh
On 01/22/2016 03:11 PM, Steve Ebersole wrote:
> On Fri, Jan 22, 2016 at 7:21 AM Radim Vansa <mailto:rva...@redhat.com>> wrote:
>
> Why should the strategy 'never be used if serializable transaction
> isolation level is required'? What guarantees it gives, a
n achieves required level of consistency. The 'locking'
term itself is a bit vague.
Does the ' you should ensure that the transaction is completed when
`Session.close()` or `Session.disconnect()` is called' still hold, or
does the transactional rework in 5.0 somehow obsolete thi
rnate_User_Guide.html
>
> Let me know what you think.
>
> Vlad
>
> On Wed, Jan 20, 2016 at 11:57 AM, Vlad Mihalcea
> mailto:mihalcea.v...@gmail.com>> wrote:
>
> Hi Radim,
>
> I'm now filling in the missing sections on the Caching chapter in
> the
ers/caching/Caching.adoc
>
> On Fri, Jan 15, 2016 at 3:48 AM Radim Vansa <mailto:rva...@redhat.com>> wrote:
>
> Hi,
>
> I was about to fill some gaps in 2LC docs regarding improvements in
> 5.0/5.1, but when I took a look into 5.0 docs [1] there's close t
/hibernate/orm/5.0/userGuide/en-US/html_single/#caching
[2]
http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html_single/#performance-cache
--
Radim Vansa
JBoss Performance Team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss
che, but in the end the implementation had flaws causing inconsistencies.
For Immutable and never removed entities, you can AFAIK safely use local
cache. However I am not aware of any means that would mark entity as
never removed, or relax the consistency for removals.
Radim
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
Radim Vansa
JBoss Performance Team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
servers although that's unrelated).
>> Not least, the fact that the app server is sticking with some version
>> shouldn't have an impact to all of our users who have no interest in
>> this particular appserver at all.
>>
>> Am I missing any important counter ar
r, Berkshire, SI4 1TE, United Kingdom.
>> Registered in UK and Wales under Company Registration No. 3798903
>> Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons
>> (USA) and Michael O'Neill (Ireland).
>>
>> ___
t; accompanied by a test case" but it directs to the JIRA main page.
>>>>>>>>
>>>>>>>> Can we let it point to the test case template repo instead:
>>>>>>>>
>>>>>>>> https://github.com/hibernate/hibernate-test-case-templates
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> --Gunnar
>>>>>>>> ___
>>>>>>>> hibernate-dev mailing list
>>>>>>>> hibernate-dev@lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> ___
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
Radim Vansa
JBoss Performance Team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
gt;
> [1] https://github.com/wildfly/wildfly/pull/8220
>
> On 10/01/2015 03:14 AM, Radim Vansa wrote:
>> Sorry Steve, as I am on a meeting this week, I did not have a chance of
>> looking into that this week, I'll make that my priority the next week.
>> Sanne has told
d disable spammy
> notifications)
> and test like as you prefer.
> If it's not allowing you such permissions, let me know.
>
> If it's not enough to diagnose this, next week I can show you
> how to
> get a root terminal on th
There is no code change between any of
> these runs.
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
Radim Vansa
JBoss Performance Team
_
On 09/09/2015 06:16 PM, Steve Ebersole wrote:
> Some comments inline and then a general discussion at the end...
>
> On Wed, Sep 9, 2015 at 10:32 AM Radim Vansa <mailto:rva...@redhat.com>> wrote:
>
> Thanks for correcting the terms, I'll try to use 'isolat
ter its own Synchronization to
> control this stuff is just asking for a lot of trouble.
>
> Anyway, this also gets into the meaning of the concurrent access
> strategies. Which access strategy are you talking about in
> particular? I assume you mean the `transactional` strategy,
lement the less strict way), but I imagine this as
something that breaks the contract a bit more, allowing even larger
performance gains (going the best-effort way without any guarantees).
Thanks for your insight!
Radim
--
Radim Vansa
JBoss Performance Team
__
t;>> https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/extension/src/main/resources/schema/jboss-as-infinispan_4_0.xsd
>>> ___
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.o
m
On 08/17/2015 01:37 PM, Sanne Grinovero wrote:
> Great, I also thought tombstones would be essential to improve the
> 2lc. Are you going to bake that feature within Infinispan or as a
> customization within the Hibernate code?
>
> On 17 August 2015 at 08:26, Radim Vansa wrote:
>&
o try
> changing the @ClassRule instances to @Rule instances and you'll see
> the test fail.
>
> Sanne
--
Radim Vansa
JBoss Performance Team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
On 07/30/2015 03:27 PM, Scott Marlow wrote:
>
>
> On 07/30/2015 02:34 AM, Radim Vansa wrote:
>> I think that the failure is caused by HHH-7898 fix. The put is executed
>> only after the current transaction is finished (as synchronization),
>> until then the query is
jboss.org/mailman/listinfo/hibernate-dev
>>
> _______
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
Radim Vansa
JBoss Performance Team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
52 matches
Mail list logo
