XAP is a distributed in-memory data grid that has high throughput and low latency due to storing all data in memory. As a result, there is 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.
- Website
- https://xap.github.io[01]
- Source Code
- https://github.com/xap/xap[02]
- Tech Docs
- https://docs.gigaspaces.com[03]
- Developer
- Country of Origin
- US
- Start Year
- 2000 [07]
- Project Types
- Commercial, Open Source
- Written in
- Java
- Supported Languages
- Java
- License
- Apache v2
XAP is a distributed in-memory data grid that has high throughput and low latency due to storing all data in memory. As a result, there is 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.
History[04]
XAP 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 or MongoDB. XAP has many similarities to NoSQL with regards to the architecture such as using a scale-out model for scalability.
Checkpoints[05]
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.
Logging[06]
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.
Citations
7 sources- XAP - In-Memory Data Grid github.io
- https://github.com/xap/xap github.com
- GigaSpaces Technical Documentation Home gigaspaces.com
- GigaSpaces - Wikipedia wikipedia.org
- https://docs.gigaspaces.com/xap/14.0/admin/controlling-the-replication-redo-log.html#recommendations gigaspaces.com
- https://docs.gigaspaces.com/xap/14.0/admin/controlling-the-replication-redo-log.html gigaspaces.com
- https://www.crunchbase.com/organization/gigaspaces-technologies#section-overview crunchbase.com