Persistent Atomic types

[Kathryn Hogg <Ka...@oati.net>]

I have a need for some atomic types to be persistent so they survive a full cluster restart.  We are using Ignite.Net 2.10

My plan is to

*         create a persistent region

*         create an ICache<string, object> or ICache<string, TV> for each value type.  The latter will be easier to add Sql support in case I ever want to dig around via SQL Api for support/debugging.

I see at least 3 different ways to make the operations atomic:


*         Use explicit locks on each key.  The main issue with this approach is getting lock requests right in the presence of failures (exceptions).  Nothing new or ground breaking but a good amount of boiler plate to correctly manage.

*         Use transactions.  The code for this is pretty clean.  Do I need to put a simple ICache<string, long>.Put() inside a transaction?

*         Use EntryProcessor.  It seems like this would lock the key while the entry processor is running but the documentation doesn't make that explicit.

What's the preferred way of implementing this?

--
Kathryn Hogg
Principal Technology Architect

Re: Persistent Atomic types

[Pavel Tupitsyn <pt...@apache.org>]

> Do I need to put a simple ICache<string, long>.Put() inside a transaction?
No. Individual entry operations are always atomic.
Note that ICache has methods like PutIfAbsent(key, val), Replace(key, old,
new),
which are useful for conditional atomic updates without transactions and
locks.

- Transactions are the best way to update multiple entries atomically (all
or nothing).
- EntryProcessor is useful for updating a single entry based on a complex
logic (e.g. "if field1 > 10 then field2 = 20")

I can give more specific advice if you share more details on your use case.

On Sun, Apr 11, 2021 at 9:56 PM Kathryn Hogg <Ka...@oati.net> wrote:

> I have a need for some atomic types to be persistent so they survive a
> full cluster restart.  We are using Ignite.Net 2.10
>
>
>
> My plan is to
>
> ·         create a persistent region
>
> ·         create an ICache<string, object> or ICache<string, TV> for each
> value type.  The latter will be easier to add Sql support in case I ever
> want to dig around via SQL Api for support/debugging.
>
>
>
> I see at least 3 different ways to make the operations atomic:
>
>
>
> ·         Use explicit locks on each key.  The main issue with this
> approach is getting lock requests right in the presence of failures
> (exceptions).  Nothing new or ground breaking but a good amount of boiler
> plate to correctly manage.
>
> ·         Use transactions.  The code for this is pretty clean.  Do I
> need to put a simple ICache<string, long>.Put() inside a transaction?
>
> ·         Use EntryProcessor.  It seems like this would lock the key
> while the entry processor is running but the documentation doesn't make
> that explicit.
>
>
>
> What's the preferred way of implementing this?
>
>
>
> --
>
> Kathryn Hogg
>
> Principal Technology Architect
>
>
>