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

Kearney, Joe Joe.Kearney at gsacapital.com
Wed Nov 23 10:46:21 EST 2011


This is exactly the Spring model of transactions with *synchronizations*, that is, operations that *synchronize with* the transaction. This is modelled using nothing more than listeners that can be registered with the transaction. For example, beforeCommit() callbacks are fired before commit and can veto the transaction commit, afterCompletion() callbacks are fired after any commit/rollback completion and failure in these is ignored.

This is fine if we're ok with having no guarantee that those listeners will be notified, but doesn't help the case of calling outside code we control before we've called commit. That's still a very separate case, and it still has to be up to the client of the transaction API/construct/whatever to ensure that these potentially bad things don't happen in the body of the transaction.

Joe

-----Original Message-----
From: concurrency-interest-bounces at cs.oswego.edu [mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf Of Gregg Wonderly
Sent: 23 November 2011 15:14
To: √iktor Ҡlang
Cc: concurrency-interest at cs.oswego.edu; gregg.wonderly at pobox.com
Subject: Re: [concurrency-interest] Transactional memory on GCC 4.7.0, what about Java?

On 11/22/2011 3:58 PM, √iktor Ҡlang wrote:
>
>
> 2011/11/22 Gregg Wonderly <gregg at cytetech.com 
> <mailto:gregg at cytetech.com>>
>
>     On 11/22/2011 12:32 PM, √iktor Ҡlang wrote:
>
>
>
>         On Tue, Nov 22, 2011 at 5:55 PM, Gregg Wonderly <gregg at cytetech.com
>         <mailto:gregg at cytetech.com>
>         <mailto:gregg at cytetech.com <mailto:gregg at cytetech.com>>> wrote:
>
>             On 11/22/2011 10:41 AM, Andrew Haley wrote:
>
>                 On 11/21/2011 10:03 PM, Rémi Forax wrote:
>
>                     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++.
>
>
>                     And how do you solve the IO problems (when you retry) ?
>
>
>                 There are basically two practical approaches to I/O:
>
>                 1.  Don't do I/O in a transaction.
>
>                 2.  Convert the transaction into a "relaxed" transaction, i.e. one
>                 that uses a single global lock.
>
>
>             I think it's better to say "one way operations", instead of I/O.
>           Basically
>             it's pointless to attempt to use transactional behavior on a one way
>             operation, unless it can not fail, in which case, you actually do
>         something like
>
>             try {
>                xxx.commit();
>                doOneWayStuff();
>             } catch( ) {
>
>             }
>
>
>         That does not compose, you need to be able to do deferred operations at
>         will.
>
>
>     Can you clarify this comment?
>
>
> methodA() {
>    changeSomething
>    changeSomethingElse
>    sendEmailsToYourCustomers
> }
>
> methodB() {
>    changeSomething
>    changeSomethingAwesome
>    drinkAShotOfJaeger
> }
>
> methodC() {
>    How do I call methodA and methodB here...
>    transaction.commit()
>    ... and have their dangerous side effects only performed 
> at-most-once here }

Okay, this is what I was alluding to.  If you can't guarantee that a one way action will have ACID properties, then you pretty much can't provide transactional behavior in any "transactional operation" which includes that action.

At best, you can just hope.  For example, in my previously mentioned distributed data application, I didn't want the clients to hold up the completion of the transaction.  There "display" updates had to be "one way" and "non-interfering" 
in behavior, because I didn't really care if they "showed the right data" or not as a controlling behavior of the system.  So, client data updates are forwarded to the clients as the last step of the processing, as the final phase of the commit.  The failure of any one of those updates is ignored.

So, the part that I want to be transactional, is.  The part that I want to see the transactional state change, sees it.  If there are problems with creating the transactional state change, processing stops, and can be retried.  If there are problems where a client closes the window halfway through the update of state sent to them, the system doesn't care, and ignores that, because we don't care whether or not that they see the update.

Gregg Wonderly
_______________________________________________
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