[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: fis-gtm



Title: Re: fis-gtm


On 07/26/2011 10:19 AM, Karsten Hilbert wrote:

On Tue, Jul 26, 2011 at 09:51:42AM -0400, Bhaskar, K.S wrote:

> [KSB3] OF course!  Sorry, I am so close to GT.M that I may miss the fact
> that what is obvious to me may not be obvious to others.
>
> GT.M has no database daemon.  GT.M processes operate with normal user ids
> and group memberships, and a process is able to access a database file
> only if its user id and group membership has access to the database file
> as determined by the database file's user / group / world permissions. 
> Details are in the security philosophy document
> (http://tinco.pair.com/bhaskar/gtm/doc/articles/GTM_Security_Philosophy.html
> is the URL; the way to always access current GT.M documentation is to go
> to http://fis-gtm.com and click on the User Documentation tab).
>
> The first process to open a database file sets up the interprocess
> communication control structures (e.g., shared memory) needed for
> multi-process / multi-user access.  The last process to close it cleans up.

In other words, GT.M is not at all a database server in the
typical sense of the word, and hardly even a server in
general.

It rather works like pretty much any odd application.

That's a big realization for packagers, I suppose.

[KSB4]  Correct, for local processes, GT.M is not a database server.  Database management occurs through cooperation between the processes accessing it.  What this means is that GT.M database throughput often goes up as the number of processes accessing it increase - depending on the application workload, this is often two to four processes per CPU/core.

There is actually a database server (GT.CM) that serves databases on remote machines via a protocol layered on top of TCP.  But the GT.CM server processes themselves run on the system like normal user processes.

Another "surprise" for people in the database world is that GT.M uses optimistic concurrency control to implement ACID (Atomic, Consistent, Isolated, Durable) transactions.

Regards
-- Bhaskar
-- 
GT.M - Rock solid. Lightning fast. Secure. No compromises.
_____________

The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
_____________

Reply to: