[concurrency-interest] Transactional memory on GCC 4.7.0, what about Java?

Gregg Wonderly gregg at cytetech.com
Tue Nov 22 09:04:11 EST 2011

A few years back, I built a multi-machine system which required that all 
machines have a mirrored copy of the systems database, and that the change of 
database content be synchronized with the operational data used by the software 
on each machine, and on any connected client computer system.

I built the transactional operations around the use of the Jini transactional 
services.  I create the synchronization around a mesh network, that was 
structured around an InvocationHandler which received inbound calls and 
guaranteed they only passed into the JVM once (within a small time interval), 
but also had references to all connected clients.  The transaction join happened 
on the inbound call.  Each method of the service API included a "CallContext" 
argument which held the transaction ID and other information.

I used an interface with "onCommit", "onPrepare" and "onAbort" methods in the 
service API methods.  The object took the call context, joined the transaction 
specified, placed itself into a static container (to maintain the reference 
chain), and then waited for the transaction owner to act.

This is pretty much the best model that I could imagine which would allow the 
transactional model to work across all the machine with a lose coupling (the 
mesh network makes it unnecessary to worry about who is a client).

Clients would connect to a server and register themselves as a listener.  They 
were called out to, on commit, and had no ability to lodge a rejection on 
prepare or commit.  They just took the call passed to them, and acted on it. 
This keeps clients from interfering with the forward progress of the system, and 
they can get a repaired view, by restarting.  In a sense, their view of the 
system was read only (they couldn't argue about the ability to commit), but they 
could modify the system transactionally.

I was not aware of the work at MS labs regarding their use of the model, but was 
driven by the mechanisms available with Jini's transactional services and the 
leasing model.

Yes, there is quite a bit of "code" involved to make this happen, but once you 
have the system wired this way, extension of the API and actions of the clients 
are pretty much as they would be for any simple client-server or "external I/O 
interface" application.

Hiding the complexity of "I/O" or "remote calls" will never be viable without an 
mechanism for the application to deal with "partial failure."  The RMI and later 
Jini (now housed in the Apache River project) work around remoting really 
demonstrates how to do transactional computing with arbitrary participants.

Gregg Wonderly

On 11/21/2011 5:26 PM, Guy Korland wrote:
> First, I think this is a discussion that should be done as part of a JSR.
> Meaning, I think the wheels should start moving and then we'll carve out the
> best solution.
> As for your questions:
> 1. There're two realistic options to handle I/O and one naiive.
>       In other words (a) you can ignore I/O or Native code call as you do with
> I/O or Native call when called under a lock context (You don't enforce any
> memory semantic). (b) you can abort any transaction trying to get outside the
> scope of the JVM. (c) you can hope for transactional I/O but it won't help for
> Native method call.
> I think a realistic solution should go with (b).
> 2. The semantic we choose in DeuceSTM was to commit a transaction that throws an
> application Exception, and that since (sadly) throwing an Exception is a valid
> way to return from method in java and pretty common. Also again when running
> under a context of coarse grained lock Exception is a valid way to get out of it.
> Guy
>     Date: Mon, 21 Nov 2011 23:03:31 +0100
>     From: R?mi Forax <forax at univ-mlv.fr <mailto:forax at univ-mlv.fr>>
>     To: concurrency-interest at cs.oswego.edu
>     <mailto:concurrency-interest at cs.oswego.edu>
>     Subject: Re: [concurrency-interest] Transactional memory on GCC 4.7.0,
>             what about Java?
>     Message-ID: <4ECACAB3.3000001 at univ-mlv.fr <mailto:4ECACAB3.3000001 at univ-mlv.fr>>
>     Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
>     On 11/21/2011 08:04 PM, Guy Korland wrote:
>      > Not all the issues are solved, but it seems like most of the issues
>      > have good answers.
>      > Also, notice that in .NET they have issues which Java doesn't have
>      > like Native code and pointers in C++.
>      >
>      > Guy
>     And how do you solve the IO problems (when you retry) ?
>     Also the semantics chosen by Microsoft when an exception is thrown
>     and the one chosen by GCC is not the same.
>     cheers,
>     R?mi
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list