RequestContext)
Hi there, just wondering, can you have multiple subscribers to a single stream (same streamId and namespace)? Or is it designed to have only one subscriber per streamId + namespace?
If it allows multiple subscribers, are all the subscriber grains guaranteed to receive all the events atleast once if you use the Azure Queue Stream Provider with ImplicitStreamSubscription?
Just kidding about Open XA, but I do agree that friendlier integration APIs would be nice. Transactions are very tricky to get right and the currently exposed API is deceptive in its apparent simplicity (just 2 methods!). I still hope we can open source one of the internal implementations
@ReubenBond Does "internal implementation" means that there are impl. of distributed transactions internally at MSFT related to Orleans?
This would be pretty huge. In my current project we are looking at Orleans because we want to scale the backend and also support linux but on the other side we have to have distributed transactions. We want to avoid Sagas because the transactions aren't long running an we don't want to create the 'undo'-actions ourselves. If there would be any guidance/example/idea from MSFT how to appraoch this problem it would be extremly helpful.
@wgross yes, Orleans has an internal implementation of distributed transactions. I posted some links to two articles above (one a technical report) which describe it.
@ReubenBond I understood that this is only for grain state or can for example a SQL server used by a grain participate in this TX?
I might have fallen into some sort of beginner trap, but does anyone know if there are limitations on how you can use null values with Orleans actor interfaces?
This works fine if both properties have a value:
var dto = new ExampleDto
{
Key = key, // string
Value = value // string
};
var result = await actor.GetWithKeyAndValue(dto, continuationToken);But if 'value' is null, Orleans instantly throws:
System.ArgumentNullException: Value cannot be null. (Parameter 'input')
at Orleans.Internal.OrleansTaskExtentions.<ToTypedTask>g__ConvertAsync|4_0[T](Task`1 asyncTask)
Hi, I'm trying to find some docs about reentrency within a call chain, but https://dotnet.github.io/orleans/docs/grains/reentrancy.html#reentrancy-within-a-call-chain doesn't exactly answer my question (maybe I'm missing something). Consider the following code:
public interface ISomeGrain : IGrainWithGuidKey
{
Task Write( int id, string content );
[AlwaysInterleave]
Task<string> Read( int id );
}
public class SomeGrain : Grain<SomeState>, ISomeGrain
{
public async Task Write( int id, string content )
{
State.Items.Add( id, content );
await WriteStateAsync();
}
public async Task<string> Read( int id )
{
if ( State.Items.ContainsKey( id ) == false )
await Write( id, "whatever" );
return State.Items[id];
}
}When Write is called from within Read will Write be working as not-interleaved? eg. will that call be properly awaited and not flux up the state? From a practical test I did, this seems to work fine. If I'm doing a loop of Write calls in Read and just execute them all with Task.WhenAll then this code will explode. Sorry if I'm getting the terminology wrong here, but I'm fairly new to this.
ArgumentNullException is not thrown from your grain code?
public async Task<string> Read( int id )
{
if ( State.Items.ContainsKey( id ) == false )
await this.GetGrain<ISomeGrain>(myKey).Write( id, "whatever" );
return State.Items[id];
}