4 projects tagged "transactions"
Updated 20 Jan 2010
STM Lib
| Pop | 18.97 |
|---|---|
| Vit | 34.84 |
STM Lib is a pragmatic library implementation of software transactional memory (STM) for Java and other JVM languages (such as Scala, Clojure, and Groovy). STM is ideal for applications where data is accessed concurrently by several threads and doesn't have to be persisted in real-time. For example, chat or instant messaging servers, file sharing servers, real time search engines, and massively multiplayer online games or virtual communities. It also works for all kinds of multithreaded programs. STMlib provides transactional collection classes that implement the standard Java APIs. The locking scheme is based on 2 phase locking, which enforces Serializability. Also, transactions are automatically retried when deadlocks occur, so you don't have to.
Updated 22 Jan 2013
JFile
| Pop | 105.57 |
|---|---|
| Vit | 10.09 |
JFile builds on JActor and Jid, adding file persistence and an in-memory database which has a throughput of one million transactions per second when running on an i7 with SSD.
Updated 05 May 2012
Automated Business Logic
| Pop | 28.35 |
|---|---|
| Vit | 19.44 |
Automated Business Logic (ABL) is a transaction logic engine. You define the behavior of your persistent objects declaratively, and the engine will take care of executing and enforcing your logic at commit time. Despite its simplicity, this approach is remarkably powerful, and can replace a large portion of the code in most transactional applications that use Hibernate.
Updated 16 May 2013
STMX
| Pop | 57.15 |
|---|---|
| Vit | 1.65 |
STMX is a high-performance Common Lisp library for composable Software Transactional Memory (STM), a concurrency control mechanism aimed at making concurrent programming easier to write and understand. Instead of traditional lock-based programming, one programs with atomic memory transactions: if a memory transaction returns normally it is committed. If it signals an error, it is rolled back. Transactions can safely run in parallel in different threads, are re-executed from the beginning in case of conflicts or if consistent reads cannot be guaranteed, and effects of a transaction are not visible from other threads until committed. This gives freedom from deadlocks, automatic rollback on failure, and aims to resolve the tension between granularity and concurrency.
