Public Member Functions
|Graph *||GetGraph ()|
|Gets the Graph instance. |
|Objects *||NewObjects ()|
|Creates a new Objects instance. |
|Begins a transaction. |
|Commits a transaction. |
All the manipulation of a Database must be enclosed into a Session. A Session can be initiated from a Database instance and allows for getting a Graph instance which represents the persistent graph (the graph database).
Also, temporary data is associated to the Session, thus when a Session is closed, all the temporary data associated to the Session is removed too. Objects or Values instances or even session attributes are an example of temporary data.
Moreover, a Session is exclusive for a thread, thus if it is shared among threads results may be fatal or unexpected.
A Session allows for enclosing a set of graph operations into a transaction. A transaction defines a granurality level for concurrent execution of Sessions. The explicit use of transactions may improve the performance of concurrent execution of Sessions.
All operations within a transaction are considered an execution unit. By default, if no transactions are defined by the user, all operations behave as autocommit, that is a transaction is created just before each method and closed when the method finishes.
For the moment, transactions have a partial support of the ACID properties.
There are two types of transactions: Read or Shared, and Write or Exclusive. DEX's concurrency model is based in a N-readers 1-writer model, thus read transactions can be executed concurrently whereas write transactions are executed exclusively.
The type of a transaction is defined for the operations it contains. Initially, a transaction starts as a read transaction and just when a method which updates the persistent graph database is found it automatically becomes a write transaction. Obviously, to become a write transaction this must wait until all other read transactions have finished.