<commit_before><commit_msg>[ci skip] Issue #7: checkpoint for getting started doc<commit_after># Getting started with Gem Servers

The gsApplicationTools project provides a framework for launching application-specific gem servers. 
A gem server is a [GemStone session](#gemstone-session) that executes an application-specific service loop within a [GemStone transaction](#gemstone-transaction).

a separate operating system process ([topaz][2]) that runs a single GemStone session.
Application-specific gem servers are needed for GsDevKit because [it is not a good idea to fork application-specific threads within a Seaside application][1].
Multiple gems

##Glossary

###GemStone Session

A GemStone session consists of four parts:
- An application, such as, [Topaz][2].
- One repository. An application has one repository to hold its persistent objects.
- One repository monitor, or Stone process, to control access to the repository.
- At least one GemStone session, or Gem process. All applications, including [Topaz][2],
  must communicate with the repository through Gem processes. A Gem provides a
  work area within which objects can be used and modified. Several Gem processes can
  coexist, communicating with the repository through a single Stone process...

*Excerpted from [Topaz Programming Environment for GemStone/S 64 Bit][2], Section 1.2*

###GemStone Transaction

GemStone prevents conflict between users by encapsulating each session’s operations
(computations, stores, and fetches) in units called transactions. The operations that make
up a transaction act on what appears to you to be a private view of GemStone objects.
When you tell GemStone to commit the current transaction, GemStone tries to merge the
modified objects in your view with the shared object store. 

#### Views and Transactions

Every user session maintains its own consistent view of the
repository state. Objects that the repository contained at the beginning of your session are
preserved in your view, even if you are not using them—and even if other users’ actions
have rendered them obsolete. The storage that those objects are using cannot be reclaimed
until you commit or abort your transaction. Depending upon the characteristics of your
particular installation (such as the number of users and the commit frequency), this
burden can be trivial or significant.
When you log in to GemStone, you get a view of repository state. After login, you may
start a transaction automatically or manually, or remain outside of transaction. The
repository view you get on login is updated when you begin a transaction or abort. When
you commit a transaction, your changes are merged with other changes to the shared data
in the repository, and your view is updated. When you obtain a new view of the
repository, by commit, abort, or continuing, any new or modified objects that have been
committed by other users become visible to you...

*Excerpted from [Programming Guide for GemStone/S 64 Bit][3], Section 8.1*

[1]: https://gemstonesoup.wordpress.com/2007/05/10/porting-application-specific-seaside-threads-to-gemstone/
[2]: http://downloads.gemtalksystems.com/docs/GemStone64/3.2.x/GS64-Topaz-3.2.pdf
[3]: http://downloads.gemtalksystems.com/docs/GemStone64/3.2.x/GS64-ProgGuide-3.2.pdf
{'fraction_non_alphanumeric': 0.05857230018303844, 'fraction_numerical': 0.012812690665039659, 'mean_word_length': 4.918772563176895, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 1, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2060892', 'n_tokens_mistral': 849, 'n_tokens_neox': 792, 'n_words': 445}