[Spread-users] Re: [mod_backhand-users] backhand & load balancer

[Theo Schlossnagle]

On Monday, September 17, 2001, at 10:19  PM, Perrin Harkins wrote:
> Sean Chittenden wrote:
>> Check out spread, kicks the snot out of databases:
>
> I mentioned Spread, and my concern about it.  It works fine for static
> data, but I'm not confident that it will replicate data fast enough to
> handle updates to data that is accessed by multiple requests in rapid
> succession, i.e. a user changes data on machine A and then wants to use
> it on machine B immediately afterward.  There is a potential for
> introducing race conditions which are not there when using sticky

I don't know if I agree.  The argument of frames in a web page doesn't 
hold.  The reason is that you wouldn't have a deterministic action even 
if it was handled on one machine.  The user can request the frames all 
at the same time and chance plays a role on which gets serviced first.

> sessions to keep a user on one machine.  Maybe some kind of distributed
> locking mechanism could fix this problem, or maybe Spread is so fast
> that this would only be a concern for sites that have to be very careful
> about data integrity, i.e. banks as opposed to discussion boards.

I think this type of integrity is important whether you are a bank or a 
discussion forum.

Distributed locking with Spread is quite easy if you have already 
exerted the effort to  handle remedial content replication with AGREED 
messages.  However, if a machine dies or gets "stuck" (app crashes, 
etc.) you need to be careful to drop or time out the lock, respectively.

But, I think that locks are unnecessary.

If you design you data store as something more intelligent than simple 
put/retrieve, then it is possible to do some cool things.  Let's say one 
of the operations on your data store (be it session state or something 
else) is find element A in the database and decrement it and find and 
increment element B.  Assume, to keep this interesting, you need to make 
this atomic.  One option is to acquire a lock and perform both actions 
and then release the lock.  This is a clean and flexible way to do it.  
But, a pain in the ass.

Instead, use a concept like stored procedures and create an "action" on 
the data store that take A and B and arguments and performs this 
operation.  So, only one AGREED message (foo(A,B)) is passed through 
Spread and the action happens IN the data store.  Locks are not 
necessary and the speed will be frightening :-)

This is an excellent approach if you have a firm grasp of the complete 
operations you will be performing on your data set and I do not think 
that requirement is so silly considering many of today's OLTP systems.  
It is like writing a "data store procedure" instead of SQL 
transactions.  I would wager most would be fairly simply (as SQL is 
often overkill for most of these transactions anyway.)

Using this, Spread can pass well over 1000 AGREED messages per second if 
they are small (as these would definitely be).

This doesn't tackle network partitions, network merges or fresh arrivals 
(joins).  That is a slightly more complicated issue :-)  Nevertheless it 
is an obstacle that can be tackled as well.

--
Theo Schlossnagle
1024D/82844984/95FD 30F1 489E 4613 F22E  491A 7E88 364C 8284 4984
2047R/33131B65/71 F7 95 64 49 76 5D BA  3D 90 B9 9F BE 27 24 E7