[jbosscache-dev] JGroups concurrent stack and parallelizing messages from the same sender

[Brian Stansberry]

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 at jboss.org
> 
> 
> 
> 
> 
> 
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev

-- 
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry at redhat.com