ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yakov Zhdanov <yzhda...@apache.org>
Subject Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Date Mon, 29 Feb 2016 10:00:00 GMT
Vlad, that's great! I will take a look this week. Reassigning ticket to
myself.

--Yakov

2016-02-26 18:37 GMT+03:00 Vladisav Jelisavcic <vladisavj@gmail.com>:

> Hi,
>
> i recently implemented distributed ReentrantLock - IGNITE-642,
> i made a pull request, so hopefully this could be added to the next
> release.
>
> Best regards,
> Vladisav
>
> On Thu, Feb 18, 2016 at 10:49 AM, Alexey Goncharuk <
> alexey.goncharuk@gmail.com> wrote:
>
> > Folks,
> >
> > The current implementation of IgniteCache.lock(key).lock() has the same
> > semantics as the transactional locks - cache topology cannot be changed
> > while there exists an ongoing transaction or an explicit lock is held.
> The
> > restriction for transactions is quite fundamental, the lock() issue can
> be
> > fixed if we re-implement locking the same way IgniteSemaphore currently
> > works.
> >
> > As for the "Failed to find semaphore with the given name" message, my
> first
> > guess is that DataStructures were configured with 1 backups which led to
> > the data loss when two nodes were stopped. Mario, can you please re-test
> > your semaphore scenario with 2 backups configured for data structures?
> > From my side, I can also take a look at the semaphore issue when I'm done
> > with IGNITE-2610.
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message