Nikolay, Ivan,
Thank you guys! I knew that I should not worry =)
Best regards,
Ivan Pavlukhin
ср, 5 февр. 2020 г. в 13:46, Ivan Rakov :
>
> Ivan,
>
> Thanks for pointing this out. Less than one day is indeed too early to
> treat this discussion thread as a "community conclusion". Still, the
>
Ivan,
Thanks for pointing this out. Less than one day is indeed too early to
treat this discussion thread as a "community conclusion". Still, the
consensus among the current participants made me feel that a conclusion
will be reached.
We'll surely get back to the discussion if opposite opinions
Ivan.
It seems we don’t have a format definition for a «community decision»
We, for sure, should fill this gap.
Me and Andrey Gura, have certain proposals for our development process based on
metrics API discussion.
We will share those proposals after 2.8 release and some additional
Folks,
A bit of offtop. Do we have some recommendations in the community how
long should we wait until treating something as "a Community
conclusion"? It worries me a little bit that I see a discussion for a
first time and there is already a conclusion. And the discussion was
started lesser than
Folks,
Thanks for your feedback.
I've created a JIRA issue on this change:
https://issues.apache.org/jira/browse/IGNITE-12622
On Tue, Feb 4, 2020 at 10:43 PM Denis Magda wrote:
> +1 from my end. It doesn't sound like a big deal if Ignite users need to
> define separate groups for atomic and
Ivan Rakov created IGNITE-12622:
---
Summary: Forbid mixed cache groups with both atomic and
transactional caches
Key: IGNITE-12622
URL: https://issues.apache.org/jira/browse/IGNITE-12622
Project: Ignite
+1 from my end. It doesn't sound like a big deal if Ignite users need to
define separate groups for atomic and transactional caches.
-
Denis
On Tue, Feb 4, 2020 at 3:28 AM Ivan Rakov wrote:
> Igniters,
>
> Apparently it's possible in Ignite to configure a cache group with both
> ATOMIC and
+1 to avoid mixed tx-atomic cache groups.
On the other side, doing atomic ops inside a tx have no relation to
described reasons and is acceptable for me.
вт, 4 февр. 2020 г. в 14:40, Alexey Goncharuk :
> I support this change. While this has no much difference on the storage
> level, the
Hello,
I absolutely agree with the proposed restriction. Additionally, this fact
should be clearly stated on the documentation page related to cache groups
https://apacheignite.readme.io/docs/cache-groups
Thanks,
S.
вт, 4 февр. 2020 г. в 14:40, Alexey Goncharuk :
> I support this change. While
I support this change. While this has no much difference on the storage
level, the protocols are indeed are very different and thus should be
separated.
вт, 4 февр. 2020 г. в 14:36, Anton Vinogradov :
> Seems, we already started the separation by atomic operations restriction
> inside the
Anton,
Indeed, that's +1 point for forbidding mixed configurations.
On Tue, Feb 4, 2020 at 2:36 PM Anton Vinogradov wrote:
> Seems, we already started the separation by atomic operations restriction
> inside the transactions [1].
> See no reason to allow mixes in this case.
>
> [1]
Seems, we already started the separation by atomic operations restriction
inside the transactions [1].
See no reason to allow mixes in this case.
[1] https://issues.apache.org/jira/browse/IGNITE-2313
On Tue, Feb 4, 2020 at 2:28 PM Ivan Rakov wrote:
> Igniters,
>
> Apparently it's possible in
Igniters,
Apparently it's possible in Ignite to configure a cache group with both
ATOMIC and TRANSACTIONAL caches.
Proof: IgniteCacheGroupsTest#testContinuousQueriesMultipleGroups* tests.
In my opinion, it would be better to remove such possibility from the
product. There are several reasons:
1)
13 matches
Mail list logo
