ISSUE 48: Transaction defaults are not optimal - proposal

[David Booz <booz@us.ibm.com>]

The JIRA description of the problem is pretty good (http://www.osoa.org/jira/browse/POLICY-48). I'll inline it for those on a plane:

=========================
It is unfortunate to have to explicitly specify something when it is the desired behavior in the vast majority of circumstances. In my opinion, components that operate in global transactions should, by default, be able to join in the transaction of the client. The more rare behavior of suspending the transaction is what should be specified if you explicitly don't want some operation to be able to join in the transaction of the client.

I'm not sure you can wire from an @ProgagatesTransaction reference to a component that is ManagedTransaction.global, if there is no interaction intent on the component."
@ManagedTransaction("global")
public class FooImpl implements Foo { ...
}

public class client {
@ProgagatesTransaction
public Foo foo;
}

@ManagedTransaction("global")
@PropogatesTransaction <<<<<====this MUST be coded to get a normally expected behavior
public class FooImpl implements Foo { ...
}

public class client {
@ProgagatesTransaction
public Foo foo;
}
==========================

Here's what the spec currently says on the matter: lines 2408-2409 follow a description of the propogatesTransaction and suspendsTransaction intents:

The absence of either interaction intent leads to runtime-specific behavior; the client is unable to determine from transaction intents whether its transaction will be joined.

PROPOSAL:
Close No Action.

Rationale:
While I agree that the issue description is compelling, the problem I see with changing the default to be 'propogatesTransaction' is that this behavior is not portable across bindings. What we'll end up with is different defaults depending on which binding is attached. If bindings are not attached until assembly time (or even later) there will be unexpected side effects. The description of the problem focuses on the context of Java in order to highlight the problem. I don't think SCA should give up binding replaceability in the assembly.


...fire away if there are other ideas.

Dave Booz
STSM, BPM and SCA Architecture
Co-Chair OASIS SCA-Policy TC and SCA-J TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
e-mail:booz@us.ibm.com