You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ignite.apache.org by ja...@gmx.de on 2021/12/07 20:22:01 UTC

Transactional Reader Writer Locks

Dear all,

 

we’re running in circles with Ignite for so long now. Can anyone please help? All our attempts to custom-build a Reader Writer Lock (/Re-entrant Lock) for use inside transactions have failed.

 

Background:

- Multi-node setup

- Very high throughput mixed read/write cache access

- Key-Value API using transactional caches

- Strong consistency absolute requirement

- Transactional context required for guarantees and fault-tolerance

 

Using Pessimistic Repeatable-Read transactions gives strong consistency but kills performance if there’s a large number of operations on the same cache entry (and they tend to introduce performance penalties in entire-cache operations and difficulties in cross-cache locking as well). All other transactional modes somehow violate the strong consistency requirement as we see it and were able to test so far.

 

In other distributed environments we use reader writer locks to gain both strong consistency and high performance with mixed workloads. In Ignite however we’re not aware that explicit locks can be used inside transactions: The documentation clearly states so (https://ignite.apache.org/docs/latest/distributed-locks) and trying to custom-build a reader writer lock for use inside transactions we always end up concluding that this may not be achievable if there are multiple ways to implicitly acquire but none to release locks. 

 

Are we out of luck here or 

- did we miss something?

- are there workarounds you know of?

- are there plans to implement transactional re-entrant locks in future releases?

 

Jay

RE: Transactional Reader Writer Locks

Posted by ja...@gmx.de.
Hi Stephen,

 

good point on the performance, yes. However, I think this will not work for us since it may give non-repeatable reads. 

 

Image the scenario with pessimistic READ_COMMITTED: 

 

Transaction A reads the balance of a bank account.

Now while A is still processing, Transaction B reads the balance and updates it.

Then transaction A updates the balance - practically overriding the update of transaction B.

Transaction B would be lost.

 

Please correct me, if I’m wrong here.

 

Jay

 

 

From: Stephen Darlington <st...@gridgain.com> 
Sent: Tuesday, 21 December 2021 14:45
To: user@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.ethan@gmx.de <ma...@gmx.de>  wrote:

 

Thanks again for the clarification Alexei. 

 

>>Ignite currently uses lock based concurrency control and is not well suited for such a scenario

 

You could still have both performance and consistency with read-heavy workloads if explicit locking inside transactions was 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 <alexey.scherbakoff@gmail.com <ma...@gmail.com> > 
Sent: Tuesday, 21 December 2021 11:51
To: user <user@ignite.apache.org <ma...@ignite.apache.org> >
Subject: Re: Transactional Reader Writer Locks

 

Note, however, that until the commit happens you can still read a partial transaction state, so the transaction logic must protect against it.

This means you shouldn't pass partial read result outside transaction scope (like writing to external storage) until a commit has happened.

 

So this basically means that in this mode all reads of an entity are sequential, right?

No, reads can be done without blocking using OPTIMISTIC SERIALIZABLE mode. This is the big difference with PESSIMISTIC REPEATABLE_READ mode.

 

Any hints on how to solve this?

I would suggest avoiding high contention on the same key. Ignite currently uses lock based concurrency control and is not well suited for such a scenario.

 

пн, 20 дек. 2021 г. в 17:27, <jay.ethan@gmx.de <ma...@gmx.de> >:

Actually, we get even worse performance with Optimistic Serializable transactions. Reason may be:

 

“[..] Another important point to note here is that a transaction fails even if an entry was read without being modified[..],since the value of the entry could be important to the logic within the initiated transaction.”

 

So this basically means that in this mode all reads of an entity are sequential, right? If so, it cannot help with performance when having a lot of reads and the need for strong consistency.

 

 

  Guys: Ignite is such an impressive product with so so many awesome 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:  <ma...@gmx.de> jay.ethan@gmx.de < <ma...@gmx.de> jay.ethan@gmx.de> 
Sent: Friday, 17 December 2021 08:44
To:  <ma...@ignite.apache.org> user@ignite.apache.org
Subject: RE: Transactional Reader Writer Locks

 

Hi Alexei

 

Thanks for your note. We have actually considered optimistic transactional transactions before but to be honest we’re not entirely sure how to address this:

 

Wiki: “When using OPTIMISTIC transactions, full read consistency can be achieved by disallowing potential conflicts between reads. This behavior is provided by OPTIMISTIC SERIALIZABLE mode. => Note, however, that until the commit happens you can still read a partial transaction state, so the transaction logic must protect against it. <=”

 

How would a tx logic look like that protects against partial transaction state in optimistic serializable mode?

 

Jay

 

 

From: Alexei Scherbakov < <ma...@gmail.com> alexey.scherbakoff@gmail.com> 
Sent: Thursday, 16 December 2021 18:10
To: user < <ma...@ignite.apache.org> user@ignite.apache.org>
Subject: Re: Transactional Reader Writer Locks

 

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, <jay.ethan@gmx.de <ma...@gmx.de> >:

Dear all,

 

we’re running in circles with Ignite for so long now. Can anyone please help? All our attempts to custom-build a Reader Writer Lock (/Re-entrant Lock) for use inside transactions have failed.

 

Background:

- Multi-node setup

- Very high throughput mixed read/write cache access

- Key-Value API using transactional caches

- Strong consistency absolute requirement

- Transactional context required for guarantees and fault-tolerance

 

Using Pessimistic Repeatable-Read transactions gives strong consistency but kills performance if there’s a large number of operations on the same cache entry (and they tend to introduce performance penalties in entire-cache operations and difficulties in cross-cache locking as well). All other transactional modes somehow violate the strong consistency requirement as we see it and were able to test so far.

 

In other distributed environments we use reader writer locks to gain both strong consistency and high performance with mixed workloads. In Ignite however we’re not aware that explicit locks can be used inside transactions: The documentation clearly states so ( <https://ignite.apache.org/docs/latest/distributed-locks> https://ignite.apache.org/docs/latest/distributed-locks) and trying to custom-build a reader writer lock for use inside transactions we always end up concluding that this may not be achievable if there are multiple ways to implicitly acquire but none to release locks. 

 

Are we out of luck here or 

- did we miss something?

- are there workarounds you know of?

- are there plans to implement transactional re-entrant locks in future releases?

 

Jay

 

 




 

-- 


Best regards,

Alexei Scherbakov




 

-- 


Best regards,

Alexei Scherbakov

Re: Transactional Reader Writer Locks

Posted by Stephen Darlington <st...@gridgain.com>.
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.ethan@gmx.de wrote:
> 
> Thanks again for the clarification Alexei. 
>  
> >>Ignite currently uses lock based concurrency control and is not well suited for such a scenario
>  
> You could still have both performance and consistency with read-heavy workloads if explicit locking inside transactions was 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 <al...@gmail.com> 
> Sent: Tuesday, 21 December 2021 11:51
> To: user <us...@ignite.apache.org>
> Subject: Re: Transactional Reader Writer Locks
>  
> Note, however, that until the commit happens you can still read a partial transaction state, so the transaction logic must protect against it.
> This means you shouldn't pass partial read result outside transaction scope (like writing to external storage) until a commit has happened.
>  
> So this basically means that in this mode all reads of an entity are sequential, right?
> No, reads can be done without blocking using OPTIMISTIC SERIALIZABLE mode. This is the big difference with PESSIMISTIC REPEATABLE_READ mode.
>  
> Any hints on how to solve this?
> I would suggest avoiding high contention on the same key. Ignite currently uses lock based concurrency control and is not well suited for such a scenario.
>  
> пн, 20 дек. 2021 г. в 17:27, <jay.ethan@gmx.de <ma...@gmx.de>>:
>> Actually, we get even worse performance with Optimistic Serializable transactions. Reason may be:
>>  
>> “[..] Another important point to note here is that a transaction fails even if an entry was read without being modified[..],since the value of the entry could be important to the logic within the initiated transaction.”
>>  
>> So this basically means that in this mode all reads of an entity are sequential, right? If so, it cannot help with performance when having a lot of reads and the need for strong consistency.
>>  
>>  
>>   Guys: Ignite is such an impressive product with so so many awesome 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.ethan@gmx.de <ma...@gmx.de> <jay.ethan@gmx.de <ma...@gmx.de>> 
>> Sent: Friday, 17 December 2021 08:44
>> To: user@ignite.apache.org <ma...@ignite.apache.org>
>> Subject: RE: Transactional Reader Writer Locks
>>  
>> Hi Alexei
>>  
>> Thanks for your note. We have actually considered optimistic transactional transactions before but to be honest we’re not entirely sure how to address this:
>>  
>> Wiki: “When using OPTIMISTIC transactions, full read consistency can be achieved by disallowing potential conflicts between reads. This behavior is provided by OPTIMISTIC SERIALIZABLE mode. => Note, however, that until the commit happens you can still read a partial transaction state, so the transaction logic must protect against it. <=”
>>  
>> How would a tx logic look like that protects against partial transaction state in optimistic serializable mode?
>>  
>> Jay
>>  
>>  
>> From: Alexei Scherbakov <alexey.scherbakoff@gmail.com <ma...@gmail.com>> 
>> Sent: Thursday, 16 December 2021 18:10
>> To: user <user@ignite.apache.org <ma...@ignite.apache.org>>
>> Subject: Re: Transactional Reader Writer Locks
>>  
>> 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, <jay.ethan@gmx.de <ma...@gmx.de>>:
>>> Dear all,
>>>  
>>> we’re running in circles with Ignite for so long now. Can anyone please help? All our attempts to custom-build a Reader Writer Lock (/Re-entrant Lock) for use inside transactions have failed.
>>>  
>>> Background:
>>> - Multi-node setup
>>> - Very high throughput mixed read/write cache access
>>> - Key-Value API using transactional caches
>>> - Strong consistency absolute requirement
>>> - Transactional context required for guarantees and fault-tolerance
>>>  
>>> Using Pessimistic Repeatable-Read transactions gives strong consistency but kills performance if there’s a large number of operations on the same cache entry (and they tend to introduce performance penalties in entire-cache operations and difficulties in cross-cache locking as well). All other transactional modes somehow violate the strong consistency requirement as we see it and were able to test so far.
>>>  
>>> In other distributed environments we use reader writer locks to gain both strong consistency and high performance with mixed workloads. In Ignite however we’re not aware that explicit locks can be used inside transactions: The documentation clearly states so (https://ignite.apache.org/docs/latest/distributed-locks <https://ignite.apache.org/docs/latest/distributed-locks>) and trying to custom-build a reader writer lock for use inside transactions we always end up concluding that this may not be achievable if there are multiple ways to implicitly acquire but none to release locks. 
>>>  
>>> Are we out of luck here or 
>>> - did we miss something?
>>> - are there workarounds you know of?
>>> - are there plans to implement transactional re-entrant locks in future releases?
>>>  
>>> Jay
>>>  
>>>  
>> 
>> 
>>  
>> -- 
>> 
>> Best regards,
>> Alexei Scherbakov
> 
> 
>  
> -- 
> 
> Best regards,
> Alexei Scherbakov

RE: Transactional Reader Writer Locks

Posted by ja...@gmx.de.
Thanks again for the clarification Alexei. 

 

>>Ignite currently uses lock based concurrency control and is not well suited for such a scenario

 

You could still have both performance and consistency with read-heavy workloads if explicit locking inside transactions was 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 <al...@gmail.com> 
Sent: Tuesday, 21 December 2021 11:51
To: user <us...@ignite.apache.org>
Subject: Re: Transactional Reader Writer Locks

 

Note, however, that until the commit happens you can still read a partial transaction state, so the transaction logic must protect against it.

This means you shouldn't pass partial read result outside transaction scope (like writing to external storage) until a commit has happened.

 

So this basically means that in this mode all reads of an entity are sequential, right?

No, reads can be done without blocking using OPTIMISTIC SERIALIZABLE mode. This is the big difference with PESSIMISTIC REPEATABLE_READ mode.

 

Any hints on how to solve this?

I would suggest avoiding high contention on the same key. Ignite currently uses lock based concurrency control and is not well suited for such a scenario.

 

пн, 20 дек. 2021 г. в 17:27, <jay.ethan@gmx.de <ma...@gmx.de> >:

Actually, we get even worse performance with Optimistic Serializable transactions. Reason may be:

 

“[..] Another important point to note here is that a transaction fails even if an entry was read without being modified [..],since the value of the entry could be important to the logic within the initiated transaction.”

 

So this basically means that in this mode all reads of an entity are sequential, right? If so, it cannot help with performance when having a lot of reads and the need for strong consistency.

 

 

  Guys: Ignite is such an impressive product with so so many awesome 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:  <ma...@gmx.de> jay.ethan@gmx.de < <ma...@gmx.de> jay.ethan@gmx.de> 
Sent: Friday, 17 December 2021 08:44
To:  <ma...@ignite.apache.org> user@ignite.apache.org
Subject: RE: Transactional Reader Writer Locks

 

Hi Alexei

 

Thanks for your note. We have actually considered optimistic transactional transactions before but to be honest we’re not entirely sure how to address this:

 

Wiki: “When using OPTIMISTIC transactions, full read consistency can be achieved by disallowing potential conflicts between reads. This behavior is provided by OPTIMISTIC SERIALIZABLE mode. => Note, however, that until the commit happens you can still read a partial transaction state, so the transaction logic must protect against it. <=”

 

How would a tx logic look like that protects against partial transaction state in optimistic serializable mode?

 

Jay

 

 

From: Alexei Scherbakov < <ma...@gmail.com> alexey.scherbakoff@gmail.com> 
Sent: Thursday, 16 December 2021 18:10
To: user < <ma...@ignite.apache.org> user@ignite.apache.org>
Subject: Re: Transactional Reader Writer Locks

 

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, <jay.ethan@gmx.de <ma...@gmx.de> >:

Dear all,

 

we’re running in circles with Ignite for so long now. Can anyone please help? All our attempts to custom-build a Reader Writer Lock (/Re-entrant Lock) for use inside transactions have failed.

 

Background:

- Multi-node setup

- Very high throughput mixed read/write cache access

- Key-Value API using transactional caches

- Strong consistency absolute requirement

- Transactional context required for guarantees and fault-tolerance

 

Using Pessimistic Repeatable-Read transactions gives strong consistency but kills performance if there’s a large number of operations on the same cache entry (and they tend to introduce performance penalties in entire-cache operations and difficulties in cross-cache locking as well). All other transactional modes somehow violate the strong consistency requirement as we see it and were able to test so far.

 

In other distributed environments we use reader writer locks to gain both strong consistency and high performance with mixed workloads. In Ignite however we’re not aware that explicit locks can be used inside transactions: The documentation clearly states so ( <https://ignite.apache.org/docs/latest/distributed-locks> https://ignite.apache.org/docs/latest/distributed-locks) and trying to custom-build a reader writer lock for use inside transactions we always end up concluding that this may not be achievable if there are multiple ways to implicitly acquire but none to release locks. 

 

Are we out of luck here or 

- did we miss something?

- are there workarounds you know of?

- are there plans to implement transactional re-entrant locks in future releases?

 

Jay

 

 




 

-- 


Best regards,

Alexei Scherbakov




 

-- 


Best regards,

Alexei Scherbakov

Re: Transactional Reader Writer Locks

Posted by Alexei Scherbakov <al...@gmail.com>.
*Note, however, that until the commit happens you can still read a partial
transaction state, so the transaction logic must protect against it.*
This means you shouldn't pass partial read result outside transaction scope
(like writing to external storage) until a commit has happened.

*So this basically means that in this mode all reads of an entity are
sequential, right?*
No, reads can be done without blocking using OPTIMISTIC SERIALIZABLE mode.
This is the big difference with PESSIMISTIC REPEATABLE_READ mode.

*Any hints on how to solve this?*
I would suggest avoiding high contention on the same key. Ignite currently
uses lock based concurrency control and is not well suited for such a
scenario.

пн, 20 дек. 2021 г. в 17:27, <ja...@gmx.de>:

> Actually, we get even worse performance with Optimistic Serializable
> transactions. Reason may be:
>
>
>
> “[..] Another important point to note here is that a transaction fails
> even if an entry was read without being modified [..],since the value of
> the entry could be important to the logic within the initiated transaction.
> ”
>
>
>
> So this basically means that in this mode all reads of an entity are
> sequential, right? If so, it cannot help with performance when having a lot
> of reads and the need for strong consistency.
>
>
>
>
>
>   Guys: Ignite is such an impressive product with so so many awesome
> 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.ethan@gmx.de <ja...@gmx.de>
> *Sent:* Friday, 17 December 2021 08:44
> *To:* user@ignite.apache.org
> *Subject:* RE: Transactional Reader Writer Locks
>
>
>
> Hi Alexei
>
>
>
> Thanks for your note. We have actually considered optimistic transactional
> transactions before but to be honest we’re not entirely sure how to address
> this:
>
>
>
> Wiki: “When using OPTIMISTIC transactions, full read consistency can be
> achieved by disallowing potential conflicts between reads. This behavior is
> provided by OPTIMISTIC SERIALIZABLE mode.* =>* *Note, however, that until
> the commit happens you can still read a partial transaction state, so the
> transaction logic must protect against it. <=*”
>
>
>
> How would a tx logic look like that protects against partial transaction
> state in optimistic serializable mode?
>
>
>
> Jay
>
>
>
>
>
> *From:* Alexei Scherbakov <al...@gmail.com>
> *Sent:* Thursday, 16 December 2021 18:10
> *To:* user <us...@ignite.apache.org>
> *Subject:* Re: Transactional Reader Writer Locks
>
>
>
> 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, <ja...@gmx.de>:
>
> Dear all,
>
>
>
> we’re running in circles with Ignite for so long now. Can anyone please
> help? All our attempts to custom-build a Reader Writer Lock (/Re-entrant
> Lock) for use inside transactions have failed.
>
>
>
> Background:
>
> - Multi-node setup
>
> - Very high throughput mixed read/write cache access
>
> - Key-Value API using transactional caches
>
> - Strong consistency absolute requirement
>
> - Transactional context required for guarantees and fault-tolerance
>
>
>
> Using Pessimistic Repeatable-Read transactions gives strong consistency
> but kills performance if there’s a large number of operations on the same
> cache entry (and they tend to introduce performance penalties in
> entire-cache operations and difficulties in cross-cache locking as well).
> All other transactional modes somehow violate the strong consistency
> requirement as we see it and were able to test so far.
>
>
>
> In other distributed environments we use reader writer locks to gain both
> strong consistency and high performance with mixed workloads. In Ignite
> however we’re not aware that explicit locks can be used inside
> transactions: The documentation clearly states so (
> https://ignite.apache.org/docs/latest/distributed-locks) and trying to
> custom-build a reader writer lock for use inside transactions we always end
> up concluding that this may not be achievable if there are multiple ways to
> implicitly acquire but none to release locks.
>
>
>
> Are we out of luck here or
>
> - did we miss something?
>
> - are there workarounds you know of?
>
> - are there plans to implement transactional re-entrant locks in future
> releases?
>
>
>
> Jay
>
>
>
>
>
>
>
>
> --
>
>
> Best regards,
>
> Alexei Scherbakov
>


-- 

Best regards,
Alexei Scherbakov

RE: Transactional Reader Writer Locks

Posted by ja...@gmx.de.
Actually, we get even worse performance with Optimistic Serializable transactions. Reason may be:

 

“[..] Another important point to note here is that a transaction fails even if an entry was read without being modified [..],since the value of the entry could be important to the logic within the initiated transaction.”

 

So this basically means that in this mode all reads of an entity are sequential, right? If so, it cannot help with performance when having a lot of reads and the need for strong consistency.

 

 

  Guys: Ignite is such an impressive product with so so many awesome 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.ethan@gmx.de <ja...@gmx.de> 
Sent: Friday, 17 December 2021 08:44
To: user@ignite.apache.org
Subject: RE: Transactional Reader Writer Locks

 

Hi Alexei

 

Thanks for your note. We have actually considered optimistic transactional transactions before but to be honest we’re not entirely sure how to address this:

 

Wiki: “When using OPTIMISTIC transactions, full read consistency can be achieved by disallowing potential conflicts between reads. This behavior is provided by OPTIMISTIC SERIALIZABLE mode. => Note, however, that until the commit happens you can still read a partial transaction state, so the transaction logic must protect against it. <=”

 

How would a tx logic look like that protects against partial transaction state in optimistic serializable mode?

 

Jay

 

 

From: Alexei Scherbakov <alexey.scherbakoff@gmail.com <ma...@gmail.com> > 
Sent: Thursday, 16 December 2021 18:10
To: user <user@ignite.apache.org <ma...@ignite.apache.org> >
Subject: Re: Transactional Reader Writer Locks

 

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, <jay.ethan@gmx.de <ma...@gmx.de> >:

Dear all,

 

we’re running in circles with Ignite for so long now. Can anyone please help? All our attempts to custom-build a Reader Writer Lock (/Re-entrant Lock) for use inside transactions have failed.

 

Background:

- Multi-node setup

- Very high throughput mixed read/write cache access

- Key-Value API using transactional caches

- Strong consistency absolute requirement

- Transactional context required for guarantees and fault-tolerance

 

Using Pessimistic Repeatable-Read transactions gives strong consistency but kills performance if there’s a large number of operations on the same cache entry (and they tend to introduce performance penalties in entire-cache operations and difficulties in cross-cache locking as well). All other transactional modes somehow violate the strong consistency requirement as we see it and were able to test so far.

 

In other distributed environments we use reader writer locks to gain both strong consistency and high performance with mixed workloads. In Ignite however we’re not aware that explicit locks can be used inside transactions: The documentation clearly states so (https://ignite.apache.org/docs/latest/distributed-locks) and trying to custom-build a reader writer lock for use inside transactions we always end up concluding that this may not be achievable if there are multiple ways to implicitly acquire but none to release locks. 

 

Are we out of luck here or 

- did we miss something?

- are there workarounds you know of?

- are there plans to implement transactional re-entrant locks in future releases?

 

Jay

 

 




 

-- 


Best regards,

Alexei Scherbakov

RE: Transactional Reader Writer Locks

Posted by ja...@gmx.de.
Hi Alexei

 

Thanks for your note. We have actually considered optimistic transactional transactions before but to be honest we’re not entirely sure how to address this:

 

Wiki: “When using OPTIMISTIC transactions, full read consistency can be achieved by disallowing potential conflicts between reads. This behavior is provided by OPTIMISTIC SERIALIZABLE mode. => Note, however, that until the commit happens you can still read a partial transaction state, so the transaction logic must protect against it. <=”

 

How would a tx logic look like that protects against partial transaction state in optimistic serializable mode?

 

Jay

 

 

From: Alexei Scherbakov <al...@gmail.com> 
Sent: Thursday, 16 December 2021 18:10
To: user <us...@ignite.apache.org>
Subject: Re: Transactional Reader Writer Locks

 

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, <jay.ethan@gmx.de <ma...@gmx.de> >:

Dear all,

 

we’re running in circles with Ignite for so long now. Can anyone please help? All our attempts to custom-build a Reader Writer Lock (/Re-entrant Lock) for use inside transactions have failed.

 

Background:

- Multi-node setup

- Very high throughput mixed read/write cache access

- Key-Value API using transactional caches

- Strong consistency absolute requirement

- Transactional context required for guarantees and fault-tolerance

 

Using Pessimistic Repeatable-Read transactions gives strong consistency but kills performance if there’s a large number of operations on the same cache entry (and they tend to introduce performance penalties in entire-cache operations and difficulties in cross-cache locking as well). All other transactional modes somehow violate the strong consistency requirement as we see it and were able to test so far.

 

In other distributed environments we use reader writer locks to gain both strong consistency and high performance with mixed workloads. In Ignite however we’re not aware that explicit locks can be used inside transactions: The documentation clearly states so (https://ignite.apache.org/docs/latest/distributed-locks) and trying to custom-build a reader writer lock for use inside transactions we always end up concluding that this may not be achievable if there are multiple ways to implicitly acquire but none to release locks. 

 

Are we out of luck here or 

- did we miss something?

- are there workarounds you know of?

- are there plans to implement transactional re-entrant locks in future releases?

 

Jay

 

 




 

-- 


Best regards,

Alexei Scherbakov

RE: RE: Transactional Reader Writer Locks

Posted by ja...@gmx.de.
Ok that’s what I was afraid of. Thanks for letting us know Pavel.

 

And if https://issues.apache.org/jira/browse/IGNITE-4887 made it back to the top of the list that would be awesome of course. You got my vote.

 

Jay

 

 

 

From: Pavel Tupitsyn <pt...@apache.org> 
Sent: Monday, 10 January 2022 07:32
To: user <us...@ignite.apache.org>
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, please use synchronous cache APIs when working with transactions.

 

A transaction is owned by a specific thread. Transactional API calls should be done from this thread, and `Commit` should be called from this thread.

When doing `await`, we most likely end up on another thread and lose transaction context.

 

There were plans to make transactions work across multiple threads, but the ticket looks abandoned:

https://issues.apache.org/jira/browse/IGNITE-4887

 

On Fri, Jan 7, 2022 at 2:23 PM <jay.ethan@gmx.de <ma...@gmx.de> > wrote:

Ok, we completed the testing:

 

Lock object cache with Optimistic Serializable transactions seems to be the way to go (thanks again Alexei).

 

We actually now prefer this approach over “classical” reader writer locks for two main reasons:

 

1) The first reason is quite obvious: When you’re using classical reader writer locks you’re in pessimistic world. And lock ordering sounds fairly easy – but can actually get quite complicated if your data model ever grows to be really complex. 

In contrast: 

Optimistic Serializable means you don’t need to worry about that but enables you to concentrate on your business logic. That’s great. Makes life simpler.

 

2) The second reason might not be as obvious at first but anyone who has allowed their users to directly trigger commands that again trigger exclusive locking in your datastore might have experienced that this way you can be taken out very, very quickly. So of course you figure that you need to do sanity-checks first but doing this non-blocking is not easy when you have strong consistency requirements (both replicating data or taking reader locks for checking first violates the consistency requirement). Then you’re excited to find the option of “upgradeable reader locks” but soon after that it turns out that in practical applications there can only be a single upgradable lock. So this doesn’t help you a lot. Then you’re back to square one since you are basically forced to acquire a write-lock before you can do the consistent sanity check which makes it just too easy to flood your servers.

In contrast:

Optimistic Serializable enables you to do fully consistent sanity checks of user traffic on a massive scale – without ever taking a single lock! Gives your servers much more room to breathe until the AI kicks in. This is a security-related feature we are starting to absolutely love!

 

Thanks again for all the input we received on this!

 

One minor issue around the approach remains:

When testing with a .NET embedded thick client (2.11.1) we only got the behaviour we needed when strictly sticking to blocking cache method calls. As soon as we introduced async/await hell broke loose and we got tons of different errors and wired behaviour. Outside transactions async/await appears to work nicely. So the question 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

 

 

From: Alexei Scherbakov <alexey.scherbakoff@gmail.com <ma...@gmail.com> > 
Sent: Thursday, 6 January 2022 12:13
To: user <user@ignite.apache.org <ma...@ignite.apache.org> >
Subject: Re: RE: Transactional Reader Writer Locks

 

Gurmehar,

"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 ." - Ignite uses record level locking.

 

Jay,

I would avoid entire cache locks due to performance reasons, but if it's really necessary, lock object cache seems the best solution.

 

 

 

вт, 28 дек. 2021 г. в 13:39, <jay.ethan@gmx.de <ma...@gmx.de> >:

Hi Thomas,

 

thanks for your feedback. 

 

We originally discarded that option since it was our understanding that this would not work as desired in a transactional context. 

 

Maybe we were wrong. Will look into it again. Thanks!

 

Jay

 

 

 

From: don.tequila@gmx.de <ma...@gmx.de>  <don.tequila@gmx.de <ma...@gmx.de> > 
Sent: Tuesday, 28 December 2021 10:59
To: user@ignite.apache.org <ma...@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/docs/latest/data-structures/semaphore

 

Then every time before reading/writing you acquire the semaphore first.

 

I guess this semaphore does essentially what you’re doing manually.

 

Regards

Thomas.

 

 

 

On 28.12.21 at 10:41, jay.ethan@gmx.de <ma...@gmx.de>  wrote: 

And if anyone knows a different way to achieve entire-cache-locks in Optimistic Serializable transactions: We always appreciate the help.

 

Jay

 

 

From: Gurmehar Kalra <gurmehar.kalra@hcl.com <ma...@hcl.com> > 
Sent: Monday, 27 December 2021 07:31
To: user@ignite.apache.org <ma...@ignite.apache.org> ; alexey.scherbakoff@gmail.com <ma...@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 update .
Please clarify .

 

Regards,

Gurmehar Singh

 

From: Alexei Scherbakov <alexey.scherbakoff@gmail.com <ma...@gmail.com> > 
Sent: 16 December 2021 22:40
To: user <user@ignite.apache.org <ma...@ignite.apache.org> >
Subject: Re: Transactional Reader Writer Locks

 

[CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.]

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, <jay.ethan@gmx.de <ma...@gmx.de> >:

Dear all,

 

we’re running in circles with Ignite for so long now. Can anyone please help? All our attempts to custom-build a Reader Writer Lock (/Re-entrant Lock) for use inside transactions have failed.

 

Background:

- Multi-node setup

- Very high throughput mixed read/write cache access

- Key-Value API using transactional caches

- Strong consistency absolute requirement

- Transactional context required for guarantees and fault-tolerance

 

Using Pessimistic Repeatable-Read transactions gives strong consistency but kills performance if there’s a large number of operations on the same cache entry (and they tend to introduce performance penalties in entire-cache operations and difficulties in cross-cache locking as well). All other transactional modes somehow violate the strong consistency requirement as we see it and were able to test so far.

 

In other distributed environments we use reader writer locks to gain both strong consistency and high performance with mixed workloads. In Ignite however we’re not aware that explicit locks can be used inside transactions: The documentation clearly states so (https://ignite.apache.org/docs/latest/distributed-locks <https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fignite.apache.org%2Fdocs%2Flatest%2Fdistributed-locks&data=04%7C01%7Cgurmehar.kalra%40hcl.com%7Cbb66d82317d148b6221608d9c0b6ee08%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637752714176933321%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=1eNvAIsE5mgD6H0CSO6IX%2BSIw2nprWcQ1KX%2B5iZfwcc%3D&reserved=0> ) and trying to custom-build a reader writer lock for use inside transactions we always end up concluding that this may not be achievable if there are multiple ways to implicitly acquire but none to release locks. 

 

Are we out of luck here or 

- did we miss something?

- are there workarounds you know of?

- are there plans to implement transactional re-entrant locks in future releases?

 

Jay

 

 




 

-- 


Best regards,

Alexei Scherbakov

::DISCLAIMER::


  _____  


The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.


  _____  





 

-- 


Best regards,

Alexei Scherbakov

Re: RE: Transactional Reader Writer Locks

Posted by Pavel Tupitsyn <pt...@apache.org>.
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, please use synchronous cache APIs when working with
transactions.

A transaction is owned by a specific thread. Transactional API calls should
be done from this thread, and `Commit` should be called from this thread.
When doing `await`, we most likely end up on another thread and lose
transaction context.

There were plans to make transactions work across multiple threads, but the
ticket looks abandoned:
https://issues.apache.org/jira/browse/IGNITE-4887

On Fri, Jan 7, 2022 at 2:23 PM <ja...@gmx.de> wrote:

> Ok, we completed the testing:
>
>
>
> Lock object cache with Optimistic Serializable transactions seems to be
> the way to go (thanks again Alexei).
>
>
>
> We actually now prefer this approach over “classical” reader writer locks
> for two main reasons:
>
>
>
> 1) The first reason is quite obvious: When you’re using classical reader
> writer locks you’re in pessimistic world. And lock ordering sounds fairly
> easy – but can actually get quite complicated if your data model ever grows
> to be really complex.
>
> In contrast:
>
> Optimistic Serializable means you don’t need to worry about that but
> enables you to concentrate on your business logic. That’s great. Makes life
> simpler.
>
>
>
> 2) The second reason might not be as obvious at first but anyone who has
> allowed their users to directly trigger commands that again trigger
> exclusive locking in your datastore might have experienced that this way
> you can be taken out very, very quickly. So of course you figure that you
> need to do sanity-checks first but doing this non-blocking is not easy when
> you have strong consistency requirements (both replicating data or taking
> reader locks for checking first violates the consistency requirement). Then
> you’re excited to find the option of “upgradeable reader locks” but soon
> after that it turns out that in practical applications there can only be a
> single upgradable lock. So this doesn’t help you a lot. Then you’re back to
> square one since you are basically forced to acquire a write-lock before
> you can do the consistent sanity check which makes it just too easy to
> flood your servers.
>
> In contrast:
>
> Optimistic Serializable enables you to do fully consistent sanity checks
> of user traffic on a massive scale – without ever taking a single lock!
> Gives your servers much more room to breathe until the AI kicks in. This is
> a security-related feature we are starting to absolutely love!
>
>
>
> Thanks again for all the input we received on this!
>
>
>
> One minor issue around the approach remains:
>
> When testing with a .NET embedded thick client (2.11.1) we only got the
> behaviour we needed when strictly sticking to blocking cache method calls.
> As soon as we introduced async/await hell broke loose and we got tons of
> different errors and wired behaviour. Outside transactions async/await
> appears to work nicely. So the question 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
>
>
>
>
>
> *From:* Alexei Scherbakov <al...@gmail.com>
> *Sent:* Thursday, 6 January 2022 12:13
> *To:* user <us...@ignite.apache.org>
> *Subject:* Re: RE: Transactional Reader Writer Locks
>
>
>
> Gurmehar,
>
> "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 ." - Ignite uses record level locking.
>
>
>
> Jay,
>
> I would avoid entire cache locks due to performance reasons, but if it's
> really necessary, lock object cache seems the best solution.
>
>
>
>
>
>
>
> вт, 28 дек. 2021 г. в 13:39, <ja...@gmx.de>:
>
> Hi Thomas,
>
>
>
> thanks for your feedback.
>
>
>
> We originally discarded that option since it was our understanding that
> this would not work as desired in a transactional context.
>
>
>
> Maybe we were wrong. Will look into it again. Thanks!
>
>
>
> Jay
>
>
>
>
>
>
>
> *From:* don.tequila@gmx.de <do...@gmx.de>
> *Sent:* Tuesday, 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/docs/latest/data-structures/semaphore
>
>
>
> Then every time before reading/writing you acquire the semaphore first.
>
>
>
> I guess this semaphore does essentially what you’re doing manually.
>
>
>
> Regards
>
> Thomas.
>
>
>
>
>
>
>
> On 28.12.21 at 10:41, jay.ethan@gmx.de wrote:
>
> And if anyone knows a different way to achieve entire-cache-locks in
> Optimistic Serializable transactions: We always appreciate the help.
>
>
>
> Jay
>
>
>
>
>
> *From:* Gurmehar Kalra <gu...@hcl.com>
> *Sent:* Monday, 27 December 2021 07:31
> *To:* user@ignite.apache.org; alexey.scherbakoff@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 update .
> Please clarify .
>
>
>
> Regards,
>
> Gurmehar Singh
>
>
>
> *From:* Alexei Scherbakov <al...@gmail.com>
> *Sent:* 16 December 2021 22:40
> *To:* user <us...@ignite.apache.org>
> *Subject:* Re: Transactional Reader Writer Locks
>
>
>
> [CAUTION: This Email is from outside the Organization. Unless you trust
> the sender, Don’t click links or open attachments as it may be a Phishing
> email, which can steal your Information and compromise your Computer.]
>
> 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, <ja...@gmx.de>:
>
> Dear all,
>
>
>
> we’re running in circles with Ignite for so long now. Can anyone please
> help? All our attempts to custom-build a Reader Writer Lock (/Re-entrant
> Lock) for use inside transactions have failed.
>
>
>
> Background:
>
> - Multi-node setup
>
> - Very high throughput mixed read/write cache access
>
> - Key-Value API using transactional caches
>
> - Strong consistency absolute requirement
>
> - Transactional context required for guarantees and fault-tolerance
>
>
>
> Using Pessimistic Repeatable-Read transactions gives strong consistency
> but kills performance if there’s a large number of operations on the same
> cache entry (and they tend to introduce performance penalties in
> entire-cache operations and difficulties in cross-cache locking as well).
> All other transactional modes somehow violate the strong consistency
> requirement as we see it and were able to test so far.
>
>
>
> In other distributed environments we use reader writer locks to gain both
> strong consistency and high performance with mixed workloads. In Ignite
> however we’re not aware that explicit locks can be used inside
> transactions: The documentation clearly states so (
> https://ignite.apache.org/docs/latest/distributed-locks
> <https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fignite.apache.org%2Fdocs%2Flatest%2Fdistributed-locks&data=04%7C01%7Cgurmehar.kalra%40hcl.com%7Cbb66d82317d148b6221608d9c0b6ee08%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637752714176933321%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=1eNvAIsE5mgD6H0CSO6IX%2BSIw2nprWcQ1KX%2B5iZfwcc%3D&reserved=0>)
> and trying to custom-build a reader writer lock for use inside transactions
> we always end up concluding that this may not be achievable if there are
> multiple ways to implicitly acquire but none to release locks.
>
>
>
> Are we out of luck here or
>
> - did we miss something?
>
> - are there workarounds you know of?
>
> - are there plans to implement transactional re-entrant locks in future
> releases?
>
>
>
> Jay
>
>
>
>
>
>
>
>
> --
>
>
> Best regards,
>
> Alexei Scherbakov
>
> ::DISCLAIMER::
> ------------------------------
>
> The contents of this e-mail and any attachment(s) are confidential and
> intended for the named recipient(s) only. E-mail transmission is not
> guaranteed to be secure or error-free as information could be intercepted,
> corrupted, lost, destroyed, arrive late or incomplete, or may contain
> viruses in transmission. The e mail and its contents (with or without
> referred errors) shall therefore not attach any liability on the originator
> or HCL or its affiliates. Views or opinions, if any, presented in this
> email are solely those of the author and may not necessarily reflect the
> views or opinions of HCL or its affiliates. Any form of reproduction,
> dissemination, copying, disclosure, modification, distribution and / or
> publication of this message without the prior written consent of authorized
> representative of HCL is strictly prohibited. If you have received this
> email in error please delete it and notify the sender immediately. Before
> opening any email and/or attachments, please check them for viruses and
> other defects.
> ------------------------------
>
>
>
>
> --
>
>
> Best regards,
>
> Alexei Scherbakov
>

RE: RE: Transactional Reader Writer Locks

Posted by ja...@gmx.de.
Ok, we completed the testing:

 

Lock object cache with Optimistic Serializable transactions seems to be the way to go (thanks again Alexei).

 

We actually now prefer this approach over “classical” reader writer locks for two main reasons:

 

1) The first reason is quite obvious: When you’re using classical reader writer locks you’re in pessimistic world. And lock ordering sounds fairly easy – but can actually get quite complicated if your data model ever grows to be really complex. 

In contrast: 

Optimistic Serializable means you don’t need to worry about that but enables you to concentrate on your business logic. That’s great. Makes life simpler.

 

2) The second reason might not be as obvious at first but anyone who has allowed their users to directly trigger commands that again trigger exclusive locking in your datastore might have experienced that this way you can be taken out very, very quickly. So of course you figure that you need to do sanity-checks first but doing this non-blocking is not easy when you have strong consistency requirements (both replicating data or taking reader locks for checking first violates the consistency requirement). Then you’re excited to find the option of “upgradeable reader locks” but soon after that it turns out that in practical applications there can only be a single upgradable lock. So this doesn’t help you a lot. Then you’re back to square one since you are basically forced to acquire a write-lock before you can do the consistent sanity check which makes it just too easy to flood your servers.

In contrast:

Optimistic Serializable enables you to do fully consistent sanity checks of user traffic on a massive scale – without ever taking a single lock! Gives your servers much more room to breathe until the AI kicks in. This is a security-related feature we are starting to absolutely love!

 

Thanks again for all the input we received on this!

 

One minor issue around the approach remains:

When testing with a .NET embedded thick client (2.11.1) we only got the behaviour we needed when strictly sticking to blocking cache method calls. As soon as we introduced async/await hell broke loose and we got tons of different errors and wired behaviour. Outside transactions async/await appears to work nicely. So the question 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

 

 

From: Alexei Scherbakov <al...@gmail.com> 
Sent: Thursday, 6 January 2022 12:13
To: user <us...@ignite.apache.org>
Subject: Re: RE: Transactional Reader Writer Locks

 

Gurmehar,

"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 ." - Ignite uses record level locking.

 

Jay,

I would avoid entire cache locks due to performance reasons, but if it's really necessary, lock object cache seems the best solution.

 

 

 

вт, 28 дек. 2021 г. в 13:39, <jay.ethan@gmx.de <ma...@gmx.de> >:

Hi Thomas,

 

thanks for your feedback. 

 

We originally discarded that option since it was our understanding that this would not work as desired in a transactional context. 

 

Maybe we were wrong. Will look into it again. Thanks!

 

Jay

 

 

 

From: don.tequila@gmx.de <ma...@gmx.de>  <don.tequila@gmx.de <ma...@gmx.de> > 
Sent: Tuesday, 28 December 2021 10:59
To: user@ignite.apache.org <ma...@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/docs/latest/data-structures/semaphore

 

Then every time before reading/writing you acquire the semaphore first.

 

I guess this semaphore does essentially what you’re doing manually.

 

Regards

Thomas.

 

 

 

On 28.12.21 at 10:41, jay.ethan@gmx.de <ma...@gmx.de>  wrote: 

And if anyone knows a different way to achieve entire-cache-locks in Optimistic Serializable transactions: We always appreciate the help.

 

Jay

 

 

From: Gurmehar Kalra <gurmehar.kalra@hcl.com <ma...@hcl.com> > 
Sent: Monday, 27 December 2021 07:31
To: user@ignite.apache.org <ma...@ignite.apache.org> ; alexey.scherbakoff@gmail.com <ma...@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 update .
Please clarify .

 

Regards,

Gurmehar Singh

 

From: Alexei Scherbakov <alexey.scherbakoff@gmail.com <ma...@gmail.com> > 
Sent: 16 December 2021 22:40
To: user <user@ignite.apache.org <ma...@ignite.apache.org> >
Subject: Re: Transactional Reader Writer Locks

 

[CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.]

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, <jay.ethan@gmx.de <ma...@gmx.de> >:

Dear all,

 

we’re running in circles with Ignite for so long now. Can anyone please help? All our attempts to custom-build a Reader Writer Lock (/Re-entrant Lock) for use inside transactions have failed.

 

Background:

- Multi-node setup

- Very high throughput mixed read/write cache access

- Key-Value API using transactional caches

- Strong consistency absolute requirement

- Transactional context required for guarantees and fault-tolerance

 

Using Pessimistic Repeatable-Read transactions gives strong consistency but kills performance if there’s a large number of operations on the same cache entry (and they tend to introduce performance penalties in entire-cache operations and difficulties in cross-cache locking as well). All other transactional modes somehow violate the strong consistency requirement as we see it and were able to test so far.

 

In other distributed environments we use reader writer locks to gain both strong consistency and high performance with mixed workloads. In Ignite however we’re not aware that explicit locks can be used inside transactions: The documentation clearly states so (https://ignite.apache.org/docs/latest/distributed-locks <https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fignite.apache.org%2Fdocs%2Flatest%2Fdistributed-locks&data=04%7C01%7Cgurmehar.kalra%40hcl.com%7Cbb66d82317d148b6221608d9c0b6ee08%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637752714176933321%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=1eNvAIsE5mgD6H0CSO6IX%2BSIw2nprWcQ1KX%2B5iZfwcc%3D&reserved=0> ) and trying to custom-build a reader writer lock for use inside transactions we always end up concluding that this may not be achievable if there are multiple ways to implicitly acquire but none to release locks. 

 

Are we out of luck here or 

- did we miss something?

- are there workarounds you know of?

- are there plans to implement transactional re-entrant locks in future releases?

 

Jay

 

 




 

-- 


Best regards,

Alexei Scherbakov

::DISCLAIMER::


  _____  


The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.


  _____  





 

-- 


Best regards,

Alexei Scherbakov

Re: RE: Transactional Reader Writer Locks

Posted by Alexei Scherbakov <al...@gmail.com>.
Gurmehar,
"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 ." - Ignite uses record level locking.

Jay,
I would avoid entire cache locks due to performance reasons, but if it's
really necessary, lock object cache seems the best solution.



вт, 28 дек. 2021 г. в 13:39, <ja...@gmx.de>:

> Hi Thomas,
>
>
>
> thanks for your feedback.
>
>
>
> We originally discarded that option since it was our understanding that
> this would not work as desired in a transactional context.
>
>
>
> Maybe we were wrong. Will look into it again. Thanks!
>
>
>
> Jay
>
>
>
>
>
>
>
> *From:* don.tequila@gmx.de <do...@gmx.de>
> *Sent:* Tuesday, 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/docs/latest/data-structures/semaphore
>
>
>
> Then every time before reading/writing you acquire the semaphore first.
>
>
>
> I guess this semaphore does essentially what you’re doing manually.
>
>
>
> Regards
>
> Thomas.
>
>
>
>
>
>
>
> On 28.12.21 at 10:41, jay.ethan@gmx.de wrote:
>
> And if anyone knows a different way to achieve entire-cache-locks in
> Optimistic Serializable transactions: We always appreciate the help.
>
>
>
> Jay
>
>
>
>
>
> *From:* Gurmehar Kalra <gu...@hcl.com>
> *Sent:* Monday, 27 December 2021 07:31
> *To:* user@ignite.apache.org; alexey.scherbakoff@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 update .
> Please clarify .
>
>
>
> Regards,
>
> Gurmehar Singh
>
>
>
> *From:* Alexei Scherbakov <al...@gmail.com>
> *Sent:* 16 December 2021 22:40
> *To:* user <us...@ignite.apache.org>
> *Subject:* Re: Transactional Reader Writer Locks
>
>
>
> [CAUTION: This Email is from outside the Organization. Unless you trust
> the sender, Don’t click links or open attachments as it may be a Phishing
> email, which can steal your Information and compromise your Computer.]
>
> 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, <ja...@gmx.de>:
>
> Dear all,
>
>
>
> we’re running in circles with Ignite for so long now. Can anyone please
> help? All our attempts to custom-build a Reader Writer Lock (/Re-entrant
> Lock) for use inside transactions have failed.
>
>
>
> Background:
>
> - Multi-node setup
>
> - Very high throughput mixed read/write cache access
>
> - Key-Value API using transactional caches
>
> - Strong consistency absolute requirement
>
> - Transactional context required for guarantees and fault-tolerance
>
>
>
> Using Pessimistic Repeatable-Read transactions gives strong consistency
> but kills performance if there’s a large number of operations on the same
> cache entry (and they tend to introduce performance penalties in
> entire-cache operations and difficulties in cross-cache locking as well).
> All other transactional modes somehow violate the strong consistency
> requirement as we see it and were able to test so far.
>
>
>
> In other distributed environments we use reader writer locks to gain both
> strong consistency and high performance with mixed workloads. In Ignite
> however we’re not aware that explicit locks can be used inside
> transactions: The documentation clearly states so (
> https://ignite.apache.org/docs/latest/distributed-locks
> <https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fignite.apache.org%2Fdocs%2Flatest%2Fdistributed-locks&data=04%7C01%7Cgurmehar.kalra%40hcl.com%7Cbb66d82317d148b6221608d9c0b6ee08%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637752714176933321%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=1eNvAIsE5mgD6H0CSO6IX%2BSIw2nprWcQ1KX%2B5iZfwcc%3D&reserved=0>)
> and trying to custom-build a reader writer lock for use inside transactions
> we always end up concluding that this may not be achievable if there are
> multiple ways to implicitly acquire but none to release locks.
>
>
>
> Are we out of luck here or
>
> - did we miss something?
>
> - are there workarounds you know of?
>
> - are there plans to implement transactional re-entrant locks in future
> releases?
>
>
>
> Jay
>
>
>
>
>
>
>
>
> --
>
>
> Best regards,
>
> Alexei Scherbakov
>
> ::DISCLAIMER::
> ------------------------------
>
> The contents of this e-mail and any attachment(s) are confidential and
> intended for the named recipient(s) only. E-mail transmission is not
> guaranteed to be secure or error-free as information could be intercepted,
> corrupted, lost, destroyed, arrive late or incomplete, or may contain
> viruses in transmission. The e mail and its contents (with or without
> referred errors) shall therefore not attach any liability on the originator
> or HCL or its affiliates. Views or opinions, if any, presented in this
> email are solely those of the author and may not necessarily reflect the
> views or opinions of HCL or its affiliates. Any form of reproduction,
> dissemination, copying, disclosure, modification, distribution and / or
> publication of this message without the prior written consent of authorized
> representative of HCL is strictly prohibited. If you have received this
> email in error please delete it and notify the sender immediately. Before
> opening any email and/or attachments, please check them for viruses and
> other defects.
> ------------------------------
>


-- 

Best regards,
Alexei Scherbakov

RE: RE: Transactional Reader Writer Locks

Posted by ja...@gmx.de.
Hi Thomas,

 

thanks for your feedback. 

 

We originally discarded that option since it was our understanding that this would not work as desired in a transactional context. 

 

Maybe we were wrong. Will look into it again. Thanks!

 

Jay

 

 

 

From: don.tequila@gmx.de <do...@gmx.de> 
Sent: Tuesday, 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/docs/latest/data-structures/semaphore

 

Then every time before reading/writing you acquire the semaphore first.

 

I guess this semaphore does essentially what you’re doing manually.

 

Regards

Thomas.

 

 

 

On 28.12.21 at 10:41, jay.ethan@gmx.de <ma...@gmx.de>  wrote: 

And if anyone knows a different way to achieve entire-cache-locks in Optimistic Serializable transactions: We always appreciate the help.

 

Jay

 

 

From: Gurmehar Kalra <gurmehar.kalra@hcl.com <ma...@hcl.com> > 
Sent: Monday, 27 December 2021 07:31
To: user@ignite.apache.org <ma...@ignite.apache.org> ; alexey.scherbakoff@gmail.com <ma...@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 update .
Please clarify .

 

Regards,

Gurmehar Singh

 

From: Alexei Scherbakov <alexey.scherbakoff@gmail.com <ma...@gmail.com> > 
Sent: 16 December 2021 22:40
To: user <user@ignite.apache.org <ma...@ignite.apache.org> >
Subject: Re: Transactional Reader Writer Locks

 

[CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.]

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, <jay.ethan@gmx.de <ma...@gmx.de> >:

Dear all,

 

we’re running in circles with Ignite for so long now. Can anyone please help? All our attempts to custom-build a Reader Writer Lock (/Re-entrant Lock) for use inside transactions have failed.

 

Background:

- Multi-node setup

- Very high throughput mixed read/write cache access

- Key-Value API using transactional caches

- Strong consistency absolute requirement

- Transactional context required for guarantees and fault-tolerance

 

Using Pessimistic Repeatable-Read transactions gives strong consistency but kills performance if there’s a large number of operations on the same cache entry (and they tend to introduce performance penalties in entire-cache operations and difficulties in cross-cache locking as well). All other transactional modes somehow violate the strong consistency requirement as we see it and were able to test so far.

 

In other distributed environments we use reader writer locks to gain both strong consistency and high performance with mixed workloads. In Ignite however we’re not aware that explicit locks can be used inside transactions: The documentation clearly states so (https://ignite.apache.org/docs/latest/distributed-locks <https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fignite.apache.org%2Fdocs%2Flatest%2Fdistributed-locks&data=04%7C01%7Cgurmehar.kalra%40hcl.com%7Cbb66d82317d148b6221608d9c0b6ee08%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637752714176933321%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=1eNvAIsE5mgD6H0CSO6IX%2BSIw2nprWcQ1KX%2B5iZfwcc%3D&reserved=0> ) and trying to custom-build a reader writer lock for use inside transactions we always end up concluding that this may not be achievable if there are multiple ways to implicitly acquire but none to release locks. 

 

Are we out of luck here or 

- did we miss something?

- are there workarounds you know of?

- are there plans to implement transactional re-entrant locks in future releases?

 

Jay

 

 




 

-- 


Best regards,

Alexei Scherbakov

::DISCLAIMER::

  _____  

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.

  _____

Re: RE: Transactional Reader Writer Locks

Posted by do...@gmx.de.
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/docs/latest/data-structures/semaphore>  

  

Then every time before reading/writing you acquire the semaphore first.

  

I guess this semaphore does essentially what you’re doing manually.

  

Regards

Thomas.

  

  

  

On 28.12.21 at 10:41, jay.ethan@gmx.de wrote:  

And if anyone knows a different way to achieve entire-cache-locks in
Optimistic Serializable transactions: We always appreciate the help.  

  

Jay





**From:** Gurmehar Kalra <gu...@hcl.com>  
**Sent:** Monday, 27 December 2021 07:31  
 **To:** user@ignite.apache.org; alexey.scherbakoff@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 update .  
Please clarify .



Regards,

Gurmehar Singh



**From:** Alexei Scherbakov
<[alexey.scherbakoff@gmail.com](mailto:alexey.scherbakoff@gmail.com)>  
**Sent:** 16 December 2021 22:40  
 **To:** user <[user@ignite.apache.org](mailto:user@ignite.apache.org)>  
 **Subject:** Re: Transactional Reader Writer Locks



[CAUTION: This Email is from outside the Organization. Unless you trust the
sender, Don’t click links or open attachments as it may be a Phishing email,
which can steal your Information and compromise your Computer.]

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, <[jay.ethan@gmx.de](mailto:jay.ethan@gmx.de)>:

> Dear all,
>
>  
>
> we’re running in circles with Ignite for so long now. Can anyone please
> help? All our attempts to custom-build a Reader Writer Lock (/Re-entrant
> Lock) for use inside transactions have failed.
>
>  
>
> Background:
>
> \- Multi-node setup
>
> \- Very high throughput mixed read/write cache access
>
> \- Key-Value API using transactional caches
>
> \- Strong consistency absolute requirement
>
> \- Transactional context required for guarantees and fault-tolerance
>
>  
>
> Using Pessimistic Repeatable-Read transactions gives strong consistency but
> kills performance if there’s a large number of operations on the same cache
> entry (and they tend to introduce performance penalties in entire-cache
> operations and difficulties in cross-cache locking as well). All other
> transactional modes somehow violate the strong consistency requirement as we
> see it and were able to test so far.
>
>  
>
> In other distributed environments we use reader writer locks to gain both
> strong consistency and high performance with mixed workloads. In Ignite
> however we’re not aware that explicit locks can be used inside transactions:
> The documentation clearly states so
> ([https://ignite.apache.org/docs/latest/distributed-
> locks](https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fignite.apache.org%2Fdocs%2Flatest%2Fdistributed-
> locks&data=04%7C01%7Cgurmehar.kalra%40hcl.com%7Cbb66d82317d148b6221608d9c0b6ee08%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637752714176933321%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=1eNvAIsE5mgD6H0CSO6IX%2BSIw2nprWcQ1KX%2B5iZfwcc%3D&reserved=0))
> and trying to custom-build a reader writer lock for use inside transactions
> we always end up concluding that this may not be achievable if there are
> multiple ways to implicitly acquire but none to release locks.
>
>  
>
> Are we out of luck here or
>
> \- did we miss something?
>
> \- are there workarounds you know of?
>
> \- are there plans to implement transactional re-entrant locks in future
> releases?
>
>  
>
> Jay
>
>  
>
>  

  



\--

  
Best regards,

Alexei Scherbakov

::DISCLAIMER::

* * *

The contents of this e-mail and any attachment(s) are confidential and
intended for the named recipient(s) only. E-mail transmission is not
guaranteed to be secure or error-free as information could be intercepted,
corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses
in transmission. The e mail and its contents (with or without referred errors)
shall therefore not attach any liability on the originator or HCL or its
affiliates. Views or opinions, if any, presented in this email are solely
those of the author and may not necessarily reflect the views or opinions of
HCL or its affiliates. Any form of reproduction, dissemination, copying,
disclosure, modification, distribution and / or publication of this message
without the prior written consent of authorized representative of HCL is
strictly prohibited. If you have received this email in error please delete it
and notify the sender immediately. Before opening any email and/or
attachments, please check them for viruses and other defects.

* * *

RE: Transactional Reader Writer Locks

Posted by ja...@gmx.de.
UPDATE:

Looks like we're close to a solution. As Alexei pointed out, reads are
concurrent in Optimistic Serializable mode. We switched to optimistic and
after we found a bug in our configuration the performance with mixed
workloads now is really great! Although some transactions require 100
attempts or more to successfully commit the overall system is almost 1000
times faster than with Pessimistic Repeatable_Read (at peak workload). This
is awesome since now we can finally use the potential of Ignite. 

 

What we still need right now (Gurmehar already pointed in that direction) is
a way to lock entire caches. We usually do this to be 100% when it comes to
ensuring consistency with inserts and deletes. Also helps to give a
consistent view when calling ContainsKey or iterating over a cache. And it
helps when you have transactions that change custom indexed fields.

 

We're currently experimenting with a very simple approach based on
Optimistic Serializable mode: We created a "cache lock object" for every
data cache in a separate "lock cache". Then, prior to every access to a data
entry we Get the corresponding cache lock object. Now if the transaction is
doing a cache-wide operation (see the 5 points above) it simply updates the
cache lock object as part of the transaction. The idea is that this should
invalidate any other transaction that is operating on the data cache at the
time, causing a performance penalty but forcing strong consistency. 

It's in a way very close to a reader-writer-lock.

 

So far, this approach looks promising. Will report our findings after we
complete the testing.

 

And if anyone knows a different way to achieve entire-cache-locks in
Optimistic Serializable transactions: We always appreciate the help.

 

Jay

 

 

From: Gurmehar Kalra <gu...@hcl.com> 
Sent: Monday, 27 December 2021 07:31
To: user@ignite.apache.org; alexey.scherbakoff@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 update .
Please clarify .

 

Regards,

Gurmehar Singh

 

From: Alexei Scherbakov <alexey.scherbakoff@gmail.com
<ma...@gmail.com> > 
Sent: 16 December 2021 22:40
To: user <user@ignite.apache.org <ma...@ignite.apache.org> >
Subject: Re: Transactional Reader Writer Locks

 

[CAUTION: This Email is from outside the Organization. Unless you trust the
sender, Don't click links or open attachments as it may be a Phishing email,
which can steal your Information and compromise your Computer.]

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, <jay.ethan@gmx.de <ma...@gmx.de> >:

Dear all,

 

we're running in circles with Ignite for so long now. Can anyone please
help? All our attempts to custom-build a Reader Writer Lock (/Re-entrant
Lock) for use inside transactions have failed.

 

Background:

- Multi-node setup

- Very high throughput mixed read/write cache access

- Key-Value API using transactional caches

- Strong consistency absolute requirement

- Transactional context required for guarantees and fault-tolerance

 

Using Pessimistic Repeatable-Read transactions gives strong consistency but
kills performance if there's a large number of operations on the same cache
entry (and they tend to introduce performance penalties in entire-cache
operations and difficulties in cross-cache locking as well). All other
transactional modes somehow violate the strong consistency requirement as we
see it and were able to test so far.

 

In other distributed environments we use reader writer locks to gain both
strong consistency and high performance with mixed workloads. In Ignite
however we're not aware that explicit locks can be used inside transactions:
The documentation clearly states so
(https://ignite.apache.org/docs/latest/distributed-locks
<https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fignite.ap
ache.org%2Fdocs%2Flatest%2Fdistributed-locks&data=04%7C01%7Cgurmehar.kalra%4
0hcl.com%7Cbb66d82317d148b6221608d9c0b6ee08%7C189de737c93a4f5a8b686f4ca99419
12%7C0%7C0%7C637752714176933321%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=1eNvAIsE5mgD6H0C
SO6IX%2BSIw2nprWcQ1KX%2B5iZfwcc%3D&reserved=0> ) and trying to custom-build
a reader writer lock for use inside transactions we always end up concluding
that this may not be achievable if there are multiple ways to implicitly
acquire but none to release locks. 

 

Are we out of luck here or 

- did we miss something?

- are there workarounds you know of?

- are there plans to implement transactional re-entrant locks in future
releases?

 

Jay

 

 




 

-- 


Best regards,

Alexei Scherbakov

::DISCLAIMER::

  _____  

The contents of this e-mail and any attachment(s) are confidential and
intended for the named recipient(s) only. E-mail transmission is not
guaranteed to be secure or error-free as information could be intercepted,
corrupted, lost, destroyed, arrive late or incomplete, or may contain
viruses in transmission. The e mail and its contents (with or without
referred errors) shall therefore not attach any liability on the originator
or HCL or its affiliates. Views or opinions, if any, presented in this email
are solely those of the author and may not necessarily reflect the views or
opinions of HCL or its affiliates. Any form of reproduction, dissemination,
copying, disclosure, modification, distribution and / or publication of this
message without the prior written consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please
delete it and notify the sender immediately. Before opening any email and/or
attachments, please check them for viruses and other defects.

  _____

RE: Transactional Reader Writer Locks

Posted by Gurmehar Kalra <gu...@hcl.com>.
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 <al...@gmail.com>
Sent: 16 December 2021 22:40
To: user <us...@ignite.apache.org>
Subject: Re: Transactional Reader Writer Locks

[CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don't click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.]
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, <ja...@gmx.de>>:
Dear all,

we're running in circles with Ignite for so long now. Can anyone please help? All our attempts to custom-build a Reader Writer Lock (/Re-entrant Lock) for use inside transactions have failed.

Background:
- Multi-node setup
- Very high throughput mixed read/write cache access
- Key-Value API using transactional caches
- Strong consistency absolute requirement
- Transactional context required for guarantees and fault-tolerance

Using Pessimistic Repeatable-Read transactions gives strong consistency but kills performance if there's a large number of operations on the same cache entry (and they tend to introduce performance penalties in entire-cache operations and difficulties in cross-cache locking as well). All other transactional modes somehow violate the strong consistency requirement as we see it and were able to test so far.

In other distributed environments we use reader writer locks to gain both strong consistency and high performance with mixed workloads. In Ignite however we're not aware that explicit locks can be used inside transactions: The documentation clearly states so (https://ignite.apache.org/docs/latest/distributed-locks<https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fignite.apache.org%2Fdocs%2Flatest%2Fdistributed-locks&data=04%7C01%7Cgurmehar.kalra%40hcl.com%7Cbb66d82317d148b6221608d9c0b6ee08%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637752714176933321%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=1eNvAIsE5mgD6H0CSO6IX%2BSIw2nprWcQ1KX%2B5iZfwcc%3D&reserved=0>) and trying to custom-build a reader writer lock for use inside transactions we always end up concluding that this may not be achievable if there are multiple ways to implicitly acquire but none to release locks.

Are we out of luck here or
- did we miss something?
- are there workarounds you know of?
- are there plans to implement transactional re-entrant locks in future releases?

Jay




--

Best regards,
Alexei Scherbakov
::DISCLAIMER::
________________________________
The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.
________________________________

Re: Transactional Reader Writer Locks

Posted by Alexei Scherbakov <al...@gmail.com>.
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, <ja...@gmx.de>:

> Dear all,
>
>
>
> we’re running in circles with Ignite for so long now. Can anyone please
> help? All our attempts to custom-build a Reader Writer Lock (/Re-entrant
> Lock) for use inside transactions have failed.
>
>
>
> Background:
>
> - Multi-node setup
>
> - Very high throughput mixed read/write cache access
>
> - Key-Value API using transactional caches
>
> - Strong consistency absolute requirement
>
> - Transactional context required for guarantees and fault-tolerance
>
>
>
> Using Pessimistic Repeatable-Read transactions gives strong consistency
> but kills performance if there’s a large number of operations on the same
> cache entry (and they tend to introduce performance penalties in
> entire-cache operations and difficulties in cross-cache locking as well).
> All other transactional modes somehow violate the strong consistency
> requirement as we see it and were able to test so far.
>
>
>
> In other distributed environments we use reader writer locks to gain both
> strong consistency and high performance with mixed workloads. In Ignite
> however we’re not aware that explicit locks can be used inside
> transactions: The documentation clearly states so (
> https://ignite.apache.org/docs/latest/distributed-locks) and trying to
> custom-build a reader writer lock for use inside transactions we always end
> up concluding that this may not be achievable if there are multiple ways
> to implicitly acquire but none to release locks.
>
>
>
> Are we out of luck here or
>
> - did we miss something?
>
> - are there workarounds you know of?
>
> - are there plans to implement transactional re-entrant locks in future
> releases?
>
>
>
> Jay
>
>
>
>
>


-- 

Best regards,
Alexei Scherbakov