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

Gregg Wonderly gregg at cytetech.com
Wed Nov 23 10:14:15 EST 2011


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


More information about the Concurrency-interest mailing list