: user
Subject: Re: RE: Transactional Reader Writer Locks
Jay,
> Is using async/await supported for optimistic serializable transactions (and
> we’re doing something wrong)
> or are transactional operations currently supposed to be blocking in .NET?
Short answer - yes, p
is:
>
>
>
>- Is using async/await supported for optimistic serializable
>transactions (and we’re doing something wrong) or are transactional
>operations currently supposed to be blocking in .NET?
>
>
>
> Thanks for any pointers.
>
>
>
> Jay
>
serializable transactions
(and we’re doing something wrong) or are transactional operations currently
supposed to be blocking in .NET?
Thanks for any pointers.
Jay
From: Alexei Scherbakov
Sent: Thursday, 6 January 2022 12:13
To: user
Subject: Re: RE: Transactional Reader Writer Locks
gt;
>
>
> Maybe we were wrong. Will look into it again. Thanks!
>
>
>
> Jay
>
>
>
>
>
>
>
> *From:* don.tequ...@gmx.de
> *Sent:* Tuesday, 28 December 2021 10:59
> *To:* user@ignite.apache.org
> *Subject:* Re: RE: Transactional Reader Writer Lock
, 28 December 2021 10:59
To: user@ignite.apache.org
Subject: Re: RE: Transactional Reader Writer Locks
Instead of creating a cache with lock objects wouldn’t it be easier to use a
semaphore for each cache where you want to achieve strong reader-Writer
consistency?
https://ignite.apache.org
From: Gurmehar Kalra Sent: Monday, 27 December 2021 07:31To: user@ignite.apache.org; alexey.scherbak...@gmail.comSubject: RE: Transactional Reader Writer Locks
Hi,I need to understand when we mean LOCK, is this lock is acquired on entire Cache or on record we are trying to update .Please
Jay
From: Gurmehar Kalra
Sent: Monday, 27 December 2021 07:31
To: user@ignite.apache.org; alexey.scherbak...@gmail.com
Subject: RE: Transactional Reader Writer Locks
Hi,
I need to understand when we mean LOCK, is this lock is acquired on entire
Cache or on record we are trying to up
Hi,
I need to understand when we mean LOCK, is this lock is acquired on entire
Cache or on record we are trying to update .
Please clarify .
Regards,
Gurmehar Singh
From: Alexei Scherbakov
Sent: 16 December 2021 22:40
To: user
Subject: Re: Transactional Reader Writer Locks
[CAUTION: This
@ignite.apache.org
Subject: Re: Transactional Reader Writer Locks
In your case it’s taking locks on reads because you have REPEATABLE_READ.
Couldn’t you avoid that by using READ_COMMITTED?
On 21 Dec 2021, at 13:41, jay.et...@gmx.de <mailto:jay.et...@gmx.de> wrote:
Thanks again f
> Just saying...
>
> Best wishes and happy holidays to you all.
>
> Jay
>
>
>
> From: Alexei Scherbakov
> Sent: Tuesday, 21 December 2021 11:51
> To: user
> Subject: Re: Transactional Reader Writer Locks
>
> Note, however, that until the com
allowed. I’m thinking in the
direction of a ‘TransactionIsolation.Explicit’.
Just saying...
Best wishes and happy holidays to you all.
Jay
From: Alexei Scherbakov
Sent: Tuesday, 21 December 2021 11:51
To: user
Subject: Re: Transactional Reader Writer Locks
Note, however, th
nd it is just
> dead-slow...
>
>
>
>
>
> Any hints on how to solve this?
>
>
>
> Appreciate it.
>
>
>
> Jay
>
>
>
>
>
>
>
> *From:* jay.et...@gmx.de
> *Sent:* Friday, 17 December 2021 08:44
> *To:* user@ignite.apache.org
>
features
but effectively we have all our data in memory - and it is just dead-slow...
Any hints on how to solve this?
Appreciate it.
Jay
From: jay.et...@gmx.de
Sent: Friday, 17 December 2021 08:44
To: user@ignite.apache.org
Subject: RE: Transactional Reader Writer Locks
action state
in optimistic serializable mode?
Jay
From: Alexei Scherbakov
Sent: Thursday, 16 December 2021 18:10
To: user
Subject: Re: Transactional Reader Writer Locks
Hi.
You can try OPTIMISTIC SERIALIZABLE isolation, it might have better throughput
in contending scenarios
Hi.
You can try OPTIMISTIC SERIALIZABLE isolation, it might have better
throughput in contending scenarios.
But this is not the same as RW lock, because a tx can be invalidated after
a commit if a lock conflict is detected.
No RW lock of any kind is planned, AFAIK.
вт, 7 дек. 2021 г. в 23:22, :
15 matches
Mail list logo
