Re: [jbosscache-dev] JGroups concurrent stack and parallelizing messages from the same sender
Manik Surtani wrote:
On 13 May 2008, at 14:22, Bela Ban wrote:
>
>
> Manik Surtani wrote:
>>
>>> You can use the above mechanism. However, you have to make sure that
>>> any thread
>>>
>>> * uses synchronous replication
>>> * the commits are synchronous as well
>>>
>>> This won't work for asynchronous replication, but I don't think it
>>> is needed here anyway right ?
>>
>> It is most critical in sync replication, correct, but why should it
>> not work with the async case as well? I'm guessing misaligned packets?
>
> Commit(A::TX-1) could be received *after* Commit(A::TX-2). Admitted, a
> rare case, but if the COMMIT(A:TX-1) is lost and needs to be
> retransmitted, this could happen
The TxInterceptor would just throw out Commit(A::TX-2) if it hasn't
received a prepare for that TX yet. Locks would still be held by TX1
assuming it's prepare has already been received.
I guess the problem is in 1-PC but that is to be expected anyway.
It's not to be expected with properly ordered messages. TX1 is sent
before TX2, just doesn't get received first (perhaps dropped by network
and retransmitted). If you remove the message ordering guarantee and
don't have some sort of ack like REPL_SYNC gives you, transactions can
be received in arbitrary order.
[Semi-OT] On his last post on the forum, fungrim said the locking issue
he was seeing was on the sender side, not the receiver. This discussion
is about removing contention on the receiver. I'm *speculating* what
he's seeing is blocking in FC.
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com