incubator-wadi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: Replication using totem protocol
Date Fri, 13 Jan 2006 19:52:49 GMT
On Jan 12, 2006, at 3:43 PM, wrote:

>> No.  You license the code to the Apache Software Foundation giving
>> the foundation the rights to relicense under any license (so the
>> foundation can upgrade the license as they did with ASL2).  We do ask
>> that you change the copyrights on the version of the code you give to
>> the ASF to something like "Copyright 2004 The Apache Software
>> Foundation or its licensors, as applicable."
> That _is_ transferring the copyright.
> As I told Jeff on the phone, I would definitely considering this if it
> turns that evs4j will really be used, but I would rather not grant  
> someone
> an unlimited license at the present time. Jeff said we are going to  
> have a
> discussion, so we'll know more soon enough.
>> Nothing better to do between jobs than coding :)
> You should see the next program I am writing ;)
>>> Also, what do you need to locks for?
>> Locking web sessions and stateful session beans in the cluster when a
>> node is working on it.
> I see. I don't think I would pass the token around all the nodes  
> just for
> session replication. It's a low-sharing workload, meaning you could  
> have
> 50 servers but you only want 3 copies of a session, say.
> But you could write a high-available lock manager using totem, say,  
> with
> three copies of the system, and write a low-latency tcp-based  
> protocol to
> grab the lock. The time to get the lock would be the tcp round-trip  
> plus
> the time it takes for totem to send itself a 'safe' message, which on
> average takes 1.5 token rotations (as opposed to 0.5). And you would
> load-balance among the three copies. That would probably get a  
> latency of
> about 5 ms total to get a lock (just a gut feeling) and also  
> scalability.
> And you can always add more copies.

Interesting.  Can you suggest a protocol we should use for  
pessimistic distributed locking?   I expect the cluster size to be  
between 2-16 nodes with the sweet spot at 4 nodes.   Each node will  
be processing about 500-1000 tps and each tps will require on average  
about 1-4 lock requests (most likely just one request for the web  
session).  Nodes should be able to join and leave the cluster easily.


View raw message