Re: Bug#541239: ITP: GT.M -- Database Engine withExtremeScalability and Robustness
On Thu, Aug 13, 2009 at 04:03:11PM -0400, K.S. Bhaskar wrote:
> [KSB] Yes, ACID transactions have been around for a while, and even
> mySQL has them now. The key difference is the software transaction
> memory and optimistic concurrency control. So, in GT.M you can
> write something like:
>
> TSTart ()
> Set ^Savings(ACN,"Balance")=^Savings(ACN,"Balance")+x
> Set ^Checking(ACN,"Balance")=^Checking(ACN,"Balance")-x
> TCommit
>
> To get full ACID properties, you just bracket the code with
> transaction markers and there is no need to lock any resources.
>
> Again, this is an important difference between GT.M and other
> database engines in the Debian / FOSS world.
No, it is not. In PostgreSQL you do exactly the same thing.
> All of the business logic executes on an originating primary
> instance. Updates are streamed from this instance to up to sixteen
> secondary instances (there is presently a 20000 kilometer distance
> limit).
Huh ? How is this enforced ? Measuring wire lag ?
> In the event of a failure, any instance downstream can become the
> new originating primary instance within seconds to tens of seconds
> (in practice, for network configuration reasons, you would probably
> want one of the sixteen connected to the primary instance to become
> the new originating primary). So this provides any desired level of
> application continuity in the face of unplanned events (such as
> system crashes, earthquakes, etc.)
Sounds pretty much like Aster.
http://www.intelligententerprise.com/blog/archives/2008/07/open_source_as.html;jsessionid=VOG4M2IPJ1XEDQE1GHOSKHWATMY32JVN
However, it is way older and thus likely better debugged on GT.M.
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Reply to: