Patching a document in the scope of an NServiceBus message

[saguiitay]

I'm trying to call Patch (Client API) from within an NServiceBus IHandleMessages<T> handler:

DocumentStore.DatabaseCommands.Patch(
               CurrentAction.Id,
               new[]
                    {
                        new PatchRequest
                            {
                                Type = PatchCommandType.Set,
                                Name = "Progress",
                                Value = value
                            }
                    }
               );

Looking at the RavenDb console, I can see the request being submitted to the server:

Request #59,104: POST    -     6 ms - <default>  - 200 - /bulk_docs
        PATCH actions/449

However, the document is not updated in the Studio UI.

Only once the NServiceBus message finishes handling (and the RavenUnitOfWork is "closed") all the patches are reflected in the document.

Notes:

• The patches are submitted via the DocumentStore, and not via the same DocumentSession used in the RavenUnitOfWork

• DocumentStore is a singleton

 

Am I missing something here?

Is it possible that NServiceBus affects the way that RavenDb's patching mechanism work, even though I'm not using the same DocumentSession?

[Kijana Woodard]

NSB processes messages in a transaction.

[saguiitay]

Does that mean that NSB adds the Patch request to the transaction?

In that case, how come I see the request on the server side?

 

Also, according to the RavenDb documentation (http://ravendb.net/docs/client-api/partial-document-updates), Patch is not transactional:

This can save bandwidth and be faster, but it is not a transactional operation, and as such only the last patching command is actually going to be persisted.

[Kijana Woodard]

Not sure.
You would see the activity, but it still hasn't committed. If exception, it would rollback.

The behavior suggests it is getting enlisted in the ambient transaction even though it wouldn't be involved in a normal raven session transaction since, as you said, this is a call off the singleton document store.

[Oren Eini (Ayende Rahien)]

Instead of using database commands, use session Defer to make sure you ate running as part of the tx

[saguiitay]

This still doesn't work.

I've changed my code to the following:

 

var value = new RavenJValue(progress);
 
using (var session = DocumentStore.OpenSession())
{
    session.Advanced.Defer(new PatchCommandData()
        {
            Key = CurrentAction.Id,
            Patches = new[]
                {
                    

new PatchRequest
                        {
                            Type = PatchCommandType.Set,
                            Name = "Progress"

,
                            Value = value
                        }
                }
        });
 
    session.SaveChanges();
}

 

And the "Progress" property is still not updated on the Studio side (I indeed see the PATCH request being send to the server when calling SaveChanges).

[Oren Eini (Ayende Rahien)]

Do you also see the TC commit?

[Kijana Woodard]

Now it's definitely part of the transaction. You won't see it until the NSB transaction commits. This is by design for NSB so you can have multiple handlers succeed or fail together as a unit per message.

[saguiitay]

@Kijana - this doesn't make sense - I have no way of writing to the database WITHOUT taking part of the transaction?!

 

@Oren - by TC you mean the Transaction Commit? I can see it at the end of the NSB message handling.

 

I've noticed something weird - after calling patch on a *new* session using the defer method, the Studio still shows the old value.

However, if I call DocumentSession.Advanced.Refresh() on the NSB session, I'm getting the correct value.

This is extremely confusing!

[Oren Eini (Ayende Rahien)]

Please show the fiddler output

[Kijana Woodard]

Yes. You could make an explicit new transaction. You probably don't want to unless you want to ensure all that code is idempotent.

[saguiitay]

Attached is the Fiddler's output.

There are 5 requests there - the first 2 are for loading the model from the database. This is fine. The next 3 are for the patching.

 

One thing that I've noticed immediately, is that the "Raven-Transaction-Information" of all the requests is the same.

This suggest that as Kijana said, the patch is being done as part of the ambient transaction, even though I've opened a new session...

[Oren Eini (Ayende Rahien)]

Can you send this as a saz file?

[saguiitay]

Sure.

Here it is.

[Oren Eini (Ayende Rahien)]

Okay, great.

I can see that you run the operation in the context of the transaction.

What I do NOT see is the actual transaction commit.

How are you running this?

[saguiitay]

Here's the full session, including the commit of the transaction.

[Oren Eini (Ayende Rahien)]

There is not PATCH here.

[saguiitay]

I apologize for this.

I must be losing my mind.

 

I've attached a new file (double checked it this time!)

[Oren Eini (Ayende Rahien)]

Sorry for not getting back earlier.

The code looks good, it looks like it should work.

Attached is a passing test