Thinking some more the old-view approach should happen on C and it
doesn't, so we're not covered.
The soutions I see here is to either replay the prepare on C as
part
of the state transfer or not to release the ST lock until the
transaction (vs the prepare command) is complete.
On Fri, Feb 10, 2012 at 12:37 PM, Mircea Markus mmar...@redhat.com wrote:
Thinking some more the old-view approach should happen on C and it
doesn't, so we're not covered.
The soutions I see here is to either replay the prepare on C as
part
of the state transfer or not to release the ST
One potential problem with this design is when we have a transaction
prepared on the old primary, and the new primary owner is a cache
that
just started. The new cache won't have any prepared transactions, so
no backup locks to prevent new transactions from acquiring the
lock.
I'm pretty
On Thu, Feb 9, 2012 at 3:07 PM, Mircea Markus mmar...@redhat.com wrote:
One potential problem with this design is when we have a transaction
prepared on the old primary, and the new primary owner is a cache
that
just started. The new cache won't have any prepared transactions, so
no backup
- Original Message -
From: Dan Berindei dan.berin...@gmail.com
To: infinispan -Dev List infinispan-dev@lists.jboss.org
Sent: Thursday, February 9, 2012 4:31:14 PM
Subject: Re: [infinispan-dev] Keeping track of locked nodes
On Thu, Feb 9, 2012 at 3:07 PM, Mircea Markus mmar
- Original Message -
From: Mircea Markus mmar...@redhat.com
To: infinispan -Dev List infinispan-dev@lists.jboss.org
Sent: Thursday, February 9, 2012 5:45:08 PM
Subject: Re: [infinispan-dev] Keeping track of locked nodes
- Original Message -
From: Dan Berindei
https://issues.jboss.org/browse/ISPN-1857
- Original Message -
From: Mircea Markus mmar...@redhat.com
To: infinispan -Dev List infinispan-dev@lists.jboss.org
Sent: Thursday, February 9, 2012 6:04:59 PM
Subject: Re: [infinispan-dev] Keeping track of locked nodes
- Original
: Re: [infinispan-dev] Keeping track of locked nodes
- Original Message -
From: Mircea Markus mmar...@redhat.com
To: infinispan -Dev List infinispan-dev@lists.jboss.org
Sent: Thursday, February 9, 2012 5:45:08 PM
Subject: Re: [infinispan-dev] Keeping track of locked nodes
In this particular case it just means that the commit is sync even if
it's configured to be async.
But there are more places where we check the remote lock nodes list,
e.g. BaseRpcInterceptor.shouldInvokeRemotely or
AbstractEnlistmentAdapter - which, incidentally, could probably settle
with a
On 20 Jan 2012, at 09:11, Dan Berindei wrote:
In this particular case it just means that the commit is sync even if
it's configured to be async.
But there are more places where we check the remote lock nodes list,
e.g. BaseRpcInterceptor.shouldInvokeRemotely or
AbstractEnlistmentAdapter -
On 20 Jan 2012, at 09:33, Manik Surtani wrote:
On 20 Jan 2012, at 14:41, Dan Berindei wrote:
In this particular case it just means that the commit is sync even if
it's configured to be async.
But there are more places where we check the remote lock nodes list,
e.g.
On 20 January 2012 11:49, Mircea Markus mircea.mar...@jboss.com wrote:
On 20 Jan 2012, at 09:33, Manik Surtani wrote:
On 20 Jan 2012, at 14:41, Dan Berindei wrote:
In this particular case it just means that the commit is sync even if
it's configured to be async.
But there are more places
Cool. Mircea, reckon we can patch this quickly and with low risk? Or is
it high risk at this stage?
I don't think it's a good moment for this right now. I'm not even convinced
that this is the way go, as it might be cheaper to cache this information
than to calculate it when needed.
On 20 January 2012 12:41, Mircea Markus mircea.mar...@jboss.com wrote:
Cool. Mircea, reckon we can patch this quickly and with low risk? Or is
it high risk at this stage?
I don't think it's a good moment for this right now. I'm not even convinced
that this is the way go, as it might be
I just noticed that org.infinispan.transaction.LocalTransaction is
keeping track of Addresses on which locks where acquired.
That's surprising me .. why should it ever be interested in the
specific Address? I'd expect it to be able to figure that out when
needed, especially since the Address
Well, a view change may not mean that the nodes prepared on have changed. But
still, there would almost certainly be a better way to do this than a
collection of addresses. So the goal is to determine whether the set of nodes
the prepare has been sent to and the current set of affected nodes
16 matches
Mail list logo
