XAP is a distributed in-memory data grid that supports the ability to conduct millions of transactions per second. This is due to the fact that there is virtually no transaction delay between physical I/O so XAP can be applied to distributed applications ranging from financial services to retail. XAP has 3 tiers to its services: Open source, Premium, and Enterprise. The open source edition supports data partitioning, event processing, and distributed execution. It also supports full transactionality by maintaining full ACID compliance.
XAP (eXtreme Application Platform) is owned by GigaSpaces, which is an Israeli software company founded in 2000 by Nati Shalom. It was designed to be used to speed up performance or scalability of many existing database systems such as MySQL and currently even supports MongoDB. XAP is integrated with MongoDB mainly for data reload and space persistency. XAP has many similarities to NoSQL with regards to the architecture such as using a scale-out model for scalability. XAP was initially developed for distributed computing but now is developed to focus on things such as real-time business intelligence.
There are two options when the redo log capacity is exceeded. The first is block-operations, where all cluster operations that need to be replicated are blocked until the redo log size decreases to below the maximum capacity. The second is drop-oldest, where the oldest packet in the redo log is dropped.
Optimistic Concurrency Control (OCC) Two-Phase Locking (Deadlock Detection)
XAP supports both optimistic concurrency control and pessimistic locking, however, OCC is the preferred strategy. With OCC, the idea is that you allow multiple users to read the same object, but only allow one user to update the object. XAP does this by maintaining a version number for each object. If multiple users try to update the same object at the same time, the ones that want to update a non-recent object will fail. This is better than pessimistic because locking may only be necessary in the worst case. OCC is executed by the user by enabling the Space Class to support OCC. When updating the object, the version ID of the updated object is compared with the corresponding object in the space. If they are the same, the version ids are incremented and updated, otherwise, the transaction is aborted.
The data model is implemented as a document store, where a document is a collection of key-value pairs. The keys are strings and the values can be types such as primitives, String, Date, or other documents so they can be nested.
XAP supports indexing over multiple properties. While indexing over multiple properties can improve read times, write times may slow down and take up more memory. XAP supports geospatial indexing implemented using an R-Tree as well as, nested property index, collection index, and dynamic indexing where indexes are dynamically added during runtime.
Read Uncommitted Read Committed Repeatable Read
XAP supports read uncommitted, read committed and repeatable reads. Read committed for XAP is implemented so that read operations return the space objects that are currently committed, even if these space objects may have been updated by an uncommitted transaction. Repeatable read is the default isolation level for XAP. For XAP, with repeatable reads, a transaction can retrieve/update the same space object as many times until the transaction is finished.
All transactions are logged to a redo log. A primary node logs all the transactions into this log and if a backup node goes down, all the data gets replayed to a new backup that is created through a recovery process. Essentially, the redo log keeps all events that need to be replicated until the primary node re-establishes a connection with the backup. The redo log can be configured in from the max capacity to the buffer size that is being used to flush packets to disk.
To query the space, XAP supports both their custom query API such as querying by template or nested property queries as well as using SQL-like syntax. Querying the space is essentially retrieving certain values from the Space Document based on a certain set of parameters. Their custom query API supports queries such as query by ID, template matching (matching by properties), or geospatial query (matching by geometry data types such as points or circles). XAP's custom SQL-like language is called SQLQuery. Some examples of SQL features they support include BETWEEN, ORDER BY, GROUP BY and some they don't support include DISTINCT, LEFT OUTER JOIN, INNER JOIN. Overall, while SQLQuery may not support some SQL features, they make up with this by supporting their custom query API.
XAP is an In-Memory database using an In-Memory Data Grid (IMDG) to store data on a grid of memory nodes. This in-memory data grid follows ACID transactional rules. The data grid essentially acts as a cache where all data is stored in memory so there are very few disk accesses, leading to a much lower latency for transactions.
XAP uses Spaces, which is an in-memory service that stores entries of information. The Space supports write, read, take, and notify and is just another name for the In-memory data grid. XAP uses these spaces to create a space-based architecture. This architecture is where all the processing units hold a partitioned part of the space.
XAP uses an in-memory data grid which partitions data based on specific attributes within the data object. As a result, the data grid uses the shared-nothing policy where each primary node has a backup which ensures consistency and highly-availability.