Multiverse is an Open Source (Apache 2 License) Software Transactional Memory implementation for the Java platform that has been under development for the last 18 months. One of the big goals for the 0.4 release was to move from a cool project to a really usable product.
Although traditional lock based concurrency control is very powerful (the internals of Multiverse rely on it), it also is very complex and error prone. The idea of (Software) Transactional Memory is to rely on transactions to prevent isolation problems and I see STM's as filling the gap between traditional lock based concurrency and traditional databases.
* optional readonly transactions
* optional read tracking
* blocking primitives like the retry/orelse for creating blocking data-structures likes stacks or queues.
* optional field level granularity
* optional writeskew prevention
* compensating and deferred task execution
* nested transactions
* basic Scala integration
* commit barriers to realise lightweight 2 phase commits.
* transactional data-structures (List, BlockingQueue, BlockingDeque)
* transactional executor
* transactional references and primitives
The goals for the 0.5 release (expected in 8 to 12 weeks):
* commuting operations (needed for better scaling data structures)
* more transactional data-structures (tree e.g.)
* non blocking transactions; similar to non blocking io where one thread
can execute more than 1 transaction.
* compile-time bytecode transformation (so no need for a javaagent)
* lots of performance improvements
Long term goals:
* many more performance improvements
* transparent persistence
* distributed transactions and distributed transactional objects.
* JEE integration (JTA/JPA etc)
* entering the eXtreme Transaction Processing arena
* contention Management
* seamless Scala & Groovy integration
Check out the site for more information:
congratulations with your 0.4 release!
Nice documentation too.
STMs have some way to (as we talked about this recently) but for so many applications I think STM is THE way to go!
Cleaner, leaner, meaner software that performs & scales, isn't that what we all want?
The overhead of STM is astonishing, but for certain mostly-I/O-bound apps, it's quite useful. Just don't think it's for everything.
Good work though, while we wait for hardware-assisted TM (yeah, right... c'mon Intel, get your act together - multiword cmpxcng isn't that hard.)
it is true there is a considerable amount of overhead. And if you want the most out of the performance i would go for a more traditional solution using locks or using non blocking algorithms (underwater in multiverse i use them as well).
I see stm's (multiverse at least) as a hybrid between traditional concurrency control and traditional databases. So you get features like blocking, lightweight Java integration where your object design is king, but also transactions, atomicity, declarative concurrency control etc. Although it will be slower that traditional concurrency control, it also will be a lot less complex and a lot more accessable for mainstream developers (you don't need to be another Doug Lea, Brian Goetz or Cliff Click)
One of the long term goals is to provide more database features like failover, (transparent) persistence, flashback queries (so go back in time and see how the world looked like at any given moment; so build in audit trail), without the usual rdbms complexity and performance wise completely blowing them out of the water doing millions of update transactions per second and an order of magnitude more readonly transactions.
But there still is a lot of room for performance improvements; especially in the instrumentation. One of the optimizations i just started to work on is to reduce the overhead of transactional object field access. What i currently do is to move all managed fields from a transactional object to a new datastructure: the tranlocal (transaction local). Once this tranlocal is retrieved, i try to carry it with the methods by widening them (so introduce extra parameters). This makes access on 'this' fields very cheap. This is one of the many optimizations planned.
...blowing them out of the water doing millions of update transactions per second and an order of magnitude more readonly transactions..
IMO, this part would be about as fast and scalable as multiversioning databases (timestamp ordering and the like) with sane caching. You would have to struggle to compete with them in the distributed case, since they have a 20+ year head start :-)
The really hard part is optimizing RW hot spots.
For me, your stuff is interesting because of the programming model (you're right, we're not all Click-ers), not performance as I don't think you can win any contest there for real-world apps until you get hardware assistance. Unfortunately, Sun's extremely interesting work in this area will probably die with Oracles financial axe.
Keep up the good work though - this is important.
The big difference performance wise is that multiverse runs in the same memoryspace as the application, perhaps even in the same cache space.
So that would give me a major performance advantage. But other approaches like coherence or gigaspaces, have already shown that for certain situations there are better alternatives than traditional relational databases.
But thanks for the support. One of the reasons to start 18 months ago with multiverse is that i wanted to understand how stm's work, and multiverse certainly helped.
But in the meantime i started to realize that stm's could be used to make enterprise developers happier. I have spend too much time on tools that were not focussed on your java objects or tools that provide the needed functionality only partially and with a lot of complexity.
I would be very happy if i could have used multiverse (give or take a few versions) on those projects.
I'm sorry, but you can't require than applications are started with an injected agent, except in exceptional cases like, say debugging.
Find another way or see your product fail!
Static instrumentation is added in the next release including maven 2 integration since that is most used build tool. Commandline (so also usable in ant) support is added as well.
The Java agents are great for developing but suck in production (and from time to time they suck in development as well since some eventual legal transformations are not allowed.
So be patient, but you can already start using it for experimental purposes.
If you want it can also be used without any instrumentation. That is how it is used in the Akka project from Jonas boner. That multiverse doesnt only want to provide à Java language solution is one of the missionstatements.
Check the site (currently on an iPhone)