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

[Manik Surtani]

On 13 May 2008, at 15:00, Brian Stansberry wrote:

> 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.

True.

> [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.

Yes, possible - but this topic is unrelated to, although sparked off  
by, fungrim's post.

--
Manik Surtani
Lead, JBoss Cache
manik at jboss.org