JSTM for GWT: An Interesting Solution for Object Replication and Synchronization

Dietrich Kappe, Friday, April 18, 2008 @ 3:00 pm

Didier Girard, the peripatetic publisher of onGWT, read my post yesterday and pointed me toward XSTM, the open source OO distributed object cache. It has Java, .NET and GWT implementations that can interoperate.

Somehow I missed Dion's two mentions (here and here) of this library. I guess "object cache" didn't trigger the right response in my brain. When I hear cache, I think of something much simpler. Digging into the background of XSTM, we find that it has it's origins in Software Transactional Memory.

In computer science, software transactional memory (STM) is a concurrency control mechanism analogous to database transactions for controlling access to shared memory in concurrent computing. It functions as an alternative to lock-based synchronization, and is typically implemented in a lock-free way. A transaction in this context is a piece of code that executes a series of reads and writes to shared memory. These reads and writes logically occur at a single instant in time; intermediate states are not visible to other (successful) transactions.

Lots of high level, abstract talk, sure. What does this really mean? From the background page:

Think of this as source control for objects. Let's say threads are developers: Today's concurrent programs are like a team of developers working without source control! Those developers would need to cooperate continuously to not write to the same files at the same time, like in in a concurrent program each thread must take care of not modifying a variable used by another one.

By using a source control solution, each developer can work on his own private view of the source code. When he is done working on this private view, and when he has verified it is tested and correct, the developer can merge it to the shared one. Only then other developers will see the modifications, and they will appear all at once. This way the shared view always jumps from a correct state to another correct state. Transactions enable this model for in memory objects.

I, for one, can't wait to take this bad boy for a spin.

Technorati Tags: ajax, gwt, xstm, shared transactional memory

agile ajax

Comments: 2 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. 

   How does solutions like XSTM stack up with memcacheD or Terracotta ? Do they address the same use cases ?

   Comment by Debasish Ghosh, Sunday, April 20, 2008 @ 11:54 pm

2. 

   Hello, thank you and Didier for this post! XSTM can be used for object caching like memcacheD or Terracotta but its more specific feature is client/server replication. E.g. to write a .NET or GWT UI for a Java server. Compared to Terracotta, XSTM is very similar but it uses optimistic locking (transactions) instead of pessimistic (distributed locks) and lacks some of their features like virtual heap, persistence etc…

   Comment by Cyprien Noel, Monday, April 21, 2008 @ 5:50 am

Leave a comment