On 01/29/2012 04:20 PM, Karsten Hilbert wrote:
On Sun, Jan 29, 2012 at 10:23:21AM -0500, Bhaskar, K.S wrote:[KSB] GT.M is both a compiler that dynamically generates object modules from source modules, as well as a NoSQL database engine. The operation of a GT.M process is entirely controlled by a number of environment variables that include variables to help a process locate routines and directories, databases, etc. In a multi-user / multi-application environment, system administrators use shell scripts to provide GT.M processes with these environment variables.All well and good - and how does GT.M handle concurrency ? If user A and user B both want to access the same database at the same time how could this typically be handled ? Can you sketch an example ? According to my understanding so far GT.M is but a highly sophisticated application writing to files on disk without a central (bunch of) process(es) handling concurrent access on behalf of users (such as is customary for server applications (think Apache, PostgreSQL, Oracle, ...).
[KSB] Yes, GT.M is unusual in high performance databases in not having a daemon. Concurrency is managed cooperatively by processes accessing a database via buffers and control structures in shared memory. The first process to open a database file sets up the shared memory and the last one to close it tears it down.
Incidentally, another unusual feature of GT.M is that for ACID transactions, it uses optimistic concurrency control, not locking.
For a simple, single-user out-of-the-box experience (install GT.M, run the "gtm" script), GT.M creates a default environment (with directories for routines, databases, etc.) under $HOME/.fis-gtm (or under any directory specified by the gtmdir environment variable).That would be a glorified MySQL running in user-local mode or even comparable to splite (in terms of conceptual structure, not in features/maturity). What happens / does GT.M do when the very same single user wants to run two instances of a frontend (client) from within on, say, X session - or from two different login sessions on the same machine - against that simple/single-user data base ? Or a third (terminal client) one from an ssh session initiated from elsewhere ?
[KSB] As I said in another post, operation is controlled by environment variables. So, if two processes have global directory files that point to the the same database files, then they access the same database. It doesn't matter where the process comes from. A process has an environment variable called gtmgbldir that points to a global directory file. A global directory file maps a logical database (a name space) to a set of files. Two processes may have the same $gtmgbldir or they may have different global directories. But the parts of the name space that maps to a database file is shared. Access by a process to a database file is based on the user-group-world permissions model (possibly as restricted by layered software such as SELinux). There is a fairly simple security model described in a technical bulletin on the GT.M user documentation page - go to http://fis-gtm.com and click on the User Documentation tab.
I have created a GT.M Acculturation Workshop that consists of a set of instructions (a web page in a zip file) that tries to explain this in more detail with a set of hands-on exercises for anyone interested. It is in the Acculturation Workshop folder at http://sourceforge.net/projects/fis-gtm/files
Regards -- Bhaskar
Karsten
-- 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.