Maxim,
You're right that the system cache is still likely to be used by plugins.
We at GridGain use it for security features, for example. As far as I know,
that's not the only case.
I also agree that the metastorage should be the preferred way for this kind
of purposes, but is there any harm in
Alexei,
One more comment: I actually think that the transaction should be the first
argument, not the last. This way it's easier to keep the API consistent.
For example, if a method uses varargs as one of the parameters, you won't
be able to put the tx parameter at the end. There might be other
I like Alexei's suggestion. This seems to be the most transparent and
explicit approach. Basically, this ensures that the user is always aware of
whether an operation is enlisted in a transaction or not. Any other option
is either error-prone, or introduces unnecessary counter-intuitive
Hi Maxim,
My congratulations!
пн, 29 нояб. 2021 г. в 19:57, Zhenya Stanilovsky :
>
>
>
> Big deal, congrats Maxim !
>
>
> >Igniters,
> >
> >The Project Management Committee (PMC) for Apache Ignite has invited Maxim
> >Timonin to become a committer and we are pleased to announce that he has
>
Big deal, congrats Maxim !
>Igniters,
>
>The Project Management Committee (PMC) for Apache Ignite has invited Maxim
>Timonin to become a committer and we are pleased to announce that he has
>accepted.
>
>Maxim makes valuable contributions to the Apache Ignite code, helps
>actively to
Congrats, Max! Well deserved
пн, 29 нояб. 2021 г. в 19:13, Kseniya Romanova :
> Igniters,
>
> The Project Management Committee (PMC) for Apache Ignite has invited Maxim
> Timonin to become a committer and we are pleased to announce that he has
> accepted.
>
> Maxim makes valuable contributions
There is JNI library in ipc/shmem directory. It even compiles with minimal
modification on modern gcc (9.3.0)
But there is no script to build jar with native library.
May be it is possible to create separate module, refactor it a bit, change
build process (CMake)?
Is there a technical reason why
Guys, what is the status of ignite-shmem and TcpCommunication through it?
1. Native part has not been built at all since 2015
2. It is currently broken in master -- I've fixed some NPE and metrics
conversion locally and it works for me. It is broken for almost a year.
3.
Igniters,
The Project Management Committee (PMC) for Apache Ignite has invited Maxim
Timonin to become a committer and we are pleased to announce that he has
accepted.
Maxim makes valuable contributions to the Apache Ignite code, helps
actively to applications developers on the user list, and
A new feedback has been added, go to bugyard.io to see all the details...
https://bugyard.io
A new feedback has been added
"our -> out
Create logical groups "our" of cluster nodes and use other Ignite APIs to
perform certain operations on the group
" by 89659245
View feedback
Alexei,
Are we going to offer an overload without tx parameter?
getAsync(K key);
getAsync(K key, Transaction tx);
On Mon, Nov 29, 2021 at 3:43 PM Alexei Scherbakov <
alexey.scherbak...@gmail.com> wrote:
> Pavel,
>
> The problem with a current approach to me is the possibility of forgetting
>
Pavel,
The problem with a current approach to me is the possibility of forgetting
to enlist a table into a transaction, because it is not enforced.
Having the explicit argument for this purpose seems less error-prone to me.
пн, 29 нояб. 2021 г. в 15:13, Pavel Tupitsyn :
> Taras, yes, yours is
Taras, yes, yours is the actual syntax in main branch right now,
I've skipped the tx argument in my code accidentally.
On Mon, Nov 29, 2021 at 3:03 PM Taras Ledkov wrote:
> Hi colleagues,
>
> 2Pavel:
> > RecordView txView = view.withTransaction();
> Can we use the syntax (see below) to
Hi colleagues,
2Pavel:
> RecordView txView = view.withTransaction();
Can we use the syntax (see below) to attach the table / operation to the
started transaction?
RecordView txPersonView =
person.recordView().withTransaction(txView.transaction());
On Mon, Nov 29, 2021 at 1:34 PM Pavel
Alexei,
I agree that runInTransaction is confusing and error-prone.
But we already have view.withTransaction(), which seems to be the most
boilerplate-free approach.
The example above will look like this:
public void testMixedPutGet() throws TransactionException {
RecordView view =
15 matches
Mail list logo
