I don't think it is as easy as that! I know of one commercial product (a JAIN SLEE) from this century where the (very smart) architects and implementors knew they didn't know how to do it in a practical telecomms environment.
It would be easier in a theoretical environment, or where there were no time constraints.
n d y
: Now
to
he trick was to lock out all versions of a data-base entry while one instan ce was being updated, and keep them all locked out until all the locked-up instances had got the up-date data and reported back. You needed a central clock to time-stamp the initial up-date. This was back around 1981, so the idea should have filtered into commercial practice by now.
Banking and credit cards system aruns on distributed data bases and do seem to work.
That a particular bunch of very smart architects and implementors didn't kn ow how to get it to work with their particular system isn't evidence that i t can't be made to work in systems with different ambitions and priorities.
Patents have been known to persuade non-patent holders to do things in very odd ways.
-- Bill Sloman, Sydney
Evidently you would be surprised at how much "not working" occurs, is hidden and regarded as "the price of doing business". I've done a little work in reconciliation in the financial sector (horrible, never again), and have glimpsed the cracks between the floorboards.
The credit card industry actually doesn't have /a/ distributed database w.r.t. money in an account. They rely on batch processing and "eventual consistency".
And people that haven't a clue about the commercial, legal and technical constraints are able to believe that they know better.
True, but I'm not aware of that being the case in the areas I mentioned.
an
and
ily
es: Now
e to
the trick was to lock out all versions of a data-base entry while one inst ance was being updated, and keep them all locked out until all the locked-u p instances had got the up-date data and reported back. You needed a centra l clock to time-stamp the initial up-date. This was back around 1981, so th e idea should have filtered into commercial practice by now.
seem to work.
That is the mechanism I got lectured about. 1981 is a decade pre-internet.
There were plenty of slow modems around working over dial-up connections, a nd quite a few local area networks - I'd gotten that particular job largely by virtue of having read a special issue of the Proceedigns of the IEEE on local area networks a few years earlier, but the idea of grabbing a whole
64-conversation T1 phone channel and using it for data was some way off.t know how to get it to work with their particular system isn't evidence th at it can't be made to work in systems with different ambitions and priorit ies.
There's a lot of that about. People who have quite a few clues have been kn own to be over-confident too. Lord Kelvin is the classic example.
very odd ways.
Would you have been? Patent issues tend to be commercical-in-confidence.
-- Bill Sloman, Sydney
Well, no - but that doesn't change the validity of your observation that the fundamentals change very slowly.
It was fun when there was a reasonable expectation that you could learn all the practically important points about that subject.
No more.
Given the very cooperative relationships between ourselves, the vendor, and Sun Microsystems, we probably would have known about any roadblocks.
The split brain problem was a problem, I've seen nothing to indicate it has disappeared, and given the fundamentals I doubt it ever will disappear.
Salesmen and youngsters will probably /believe/ it doesn't exist, but that's a different kettle of fish!
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.