[Spread-users] Re: [mod_backhand-users] backhand & load balancer
jesus at omniti.com
Mon Sep 17 23:42:54 EDT 2001
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
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.
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
More information about the Spread-users