Disable client caching

[DanPlaskon]

Is there a way to disable the caching that now takes place on the
client through configuration?

[Bruno Lopes]

IIRC look at the conventions on the documentstore and search for a "shouldcacherequest" or something. Set it to (url) => false .

[Ayende Rahien]

Yes, it is on the conventions, there is a lambda you can pass.

I only added it for completion sake, though.

Why do you want that?

[DanPlaskon]

Thanks guys, figured that out finally.

As to "why I need this"...I can't be entirely sure...but I think it's
messing with my transaction semantics somehow, all of my integration
tests begin failing after updating to the latest stable build.
Disabling the client cache seems to have solved this for whatever
reason.

I will reply with further details once I get to the bottom of this
myself.

> > client through configuration?- Hide quoted text -
>
> - Show quoted text -

[DanPlaskon]

To expand a little; I seem to be hitting an awful lot of these:

Raven.Http.Exceptions.ConcurrencyException : A document with key:
'shortenedurls/
gJsNflIHcP4WbxAjCyQqlRa4jA3pz54hXhs0aivlWjXEc1S5pneE4z1aJxsdxdTUJAz1SmliuVy9PY
+zwkoo3g==' is currently created in another transaction at
Raven.Client.Client.ServerClient.DirectBatch(IEnumerable`1
commandDatas, String operationUrl) at
Raven.Client.Client.ServerClient.<>c__DisplayClass2c.b__2b(String u)
at Raven.Client.Client.ServerClient.TryOperation[T](Func`2 operation,
String operationUrl, Boolean avoidThrowing, T& result) at
Raven.Client.Client.ServerClient.ExecuteWithReplication[T](Func`2
operation) at Raven.Client.Client.ServerClient.Batch(IEnumerable`1
commandDatas) at Raven.Client.Document.DocumentSession.SaveChanges()

No changes whatsoever have been made to the codebase other than the
update to the latest stable build...any ideas?

> > - Show quoted text -- Hide quoted text -

[Ayende Rahien]

Well... Can you share the actual code?

It might be that caching ignores the ambient transaction 

[DanPlaskon]

Ayende,

Disabling the caching didn't seem to have any affect (assuming the
following is the proper way to configure that):

documentStore = new DocumentStore { ConnectionStringName =
connectionStringNames.DocumentDatabase };
documentStore.Conventions.ShouldCacheRequest = url => false;
documentStore.Initialize();

Giving a representative sample is pretty difficult (I'll see if I can
put something simple together) because the infrastructure of the
application is pretty heavily layered.

Essentially, it's an asp.net mvc application in which every controller
action runs within a transaction scope...usually both nhibernate and
ravendb operate within the scope. The new update seems to fail in this
type of scenario for whatever reason.

So something like

' Assuming: Operating within TransactionScope.....

Public Sub SaveUserPreferences(ByVal preferences As
UserPreferencesDetails)

Dim documentId = CreateDocumentIdFor(preferences.UserId)

Dim userPrefs = Session.Load(Of UserPreferences)
(documentId)

If userPrefs Is Nothing Then

userPrefs = New UserPreferences(documentId,
preferences.UserId, preferences.Preferences)

Session.Store(userPrefs)

Else

userPrefs.Preferences = preferences.Preferences

End If

Session.SaveChanges()

End Sub

Causes:

Raven.Http.Exceptions.ConcurrencyException : A document with key:

'userpreferences/1' is currently created in another transaction

To be thrown.....

Honestly, I'm at the point where I'm considering reverting back to
build 206 because it had no such problem in this scenario.

If there's further details you think would be helpful for me to post,
please don't hesitate to ask.

On Jan 26, 1:50 am, Ayende Rahien <aye...@ayende.com> wrote:
> Well... Can you share the actual code?
> It might be that caching ignores the ambient transaction
>
>
>
> On Tue, Jan 25, 2011 at 11:54 PM, DanPlaskon <dplas...@gmail.com> wrote:
> > To expand a little; I seem to be hitting an awful lot of these:
>
> > Raven.Http.Exceptions.ConcurrencyException : A document with key:
> > 'shortenedurls/
>

> > gJsNflIHcP4WbxAjCyQqlRa4jA3pz54hXhs0aivlWjXEc1S5pneE4z1aJxsdxdTUJAz1SmliuVy­9PY

[Ayende Rahien]

It is possible that you are running this in parallel? So two transactions are hitting the same codebase?

[DanPlaskon]

Ayende,

No, I don't think that could be the case.

[Ayende Rahien]

What is the console output when this happens?

[DanPlaskon]

Ok..a few hours sleep was certainly helpful....

The lifecycle of my request looks roughly like this:

1) open document session
2) begin tx scope
3) begin nhibernate session
4) committ tx scope
5) dispose document session

I felt this was less-than-elegant, but did so in an attempt to
integration raven as seamlessly as possible into an existing
application. For whatever reason, this series of interations worked
fine on build 206, but not on build 264. Obviously I'm going to need
to rethink my approach to this; but any ideas as to why this suddently
stopped working?

[DanPlaskon]

Stranger yet...when I switched to a (temporary) strategy where I only
opened a document session for each raven service method, this problem
continues to persist...so usage is now something like:

begin tx scope

begin nhibernate session

begin document session
// do raven stuff
dispose document session

begin document session
// do raven stuff
dispose document session

dispose nhibernate session

commit tx scope

I'm going to see if I can put together a simple unit test to
demostrate this...I suspect the newest build may have some sort of
overall problem with being used in conjunction with a transactionscope

[DanPlaskon]

Alright...I have distilled this down to its simiplest possible form
and can confirm that there is indeed something up with
TransactionScopes in general....

Take for instance this extremely simple demo (targetting .NET 3.5 if
relevant):

Imports System.Transactions
Imports Raven.Database.Data
Imports Raven.Client
Imports Raven.Client.Document

Public Module Module1

Public Class Tester
Public Property Id As String
Public Property Name As String
End Class

Sub Main()

Dim docStore As New DocumentStore() With
{.ConnectionStringName = "Documents"}
docStore.Conventions.ShouldCacheRequest = Function(x) False
docStore.Initialize()


Using tx As New TransactionScope

Using session = docStore.OpenSession()
Dim x = New Tester()
x.Id = "Tester123"
x.Name = "Blah"
session.Store(x)
session.SaveChanges()
End Using

tx.Complete()

End Using

Using session = docStore.OpenSession()
Dim x = New Tester()
x.Id = "Tester1234"
x.Name = "Blah123"
session.Store(x)
session.SaveChanges()
End Using


End Sub

End Module

With a connection string as follows (this is a remote matchine running
in service mode, if that's relevant)

<add name="Documents" connectionString="url=http://myserver:
8080;defaultdatabase=TxIssueDatabase;user=beam;password=meup"/>

Upon executing the above, and visiting the web interface for the
"TxIssueDatabase" tenant, I can see the second document stored without
a transaction scope, but not the first one.....

Am I doing something incorrect here, or is this indeed a bug in raven?

[Ayende Rahien]

Okay, I know what is likely causing this.

Thanks, I'll fix this tomorrow.

[DanPlaskon]

Ayende,

Cool..thanks!

Will this appear as an "unstable" build at some point tomorrow? I'm
just considering whether or not I should revert back to 206 in the
mean time if it's going to be awhile before this is resolved
completely.

[Ayende Rahien]

Yes, it will be in the unstable.

Build 261 should fix the issue for you, it was introduce in 262

[Ayende Rahien]

Fixed,

Please note that this is a bug in the stable fork as well, and will result in a new stable release tomorrow

[DanPlaskon]

Yup, looks like we're back in business - thanks for fixing this one so
quickly!

On Jan 27, 4:34 am, Ayende Rahien <aye...@ayende.com> wrote:
> Fixed,
> Please note that this is a bug in the stable fork as well, and will result
> in a new stable release tomorrow
>
>
>
> On Wed, Jan 26, 2011 at 6:17 PM, Ayende Rahien <aye...@ayende.com> wrote:
> > Yes, it will be in the unstable.
> > Build 261 should fix the issue for you, it was introduce in 262
>

> ...
>
> read more »- Hide quoted text -

[Mike McGranahan]

I appear to be having the same (or similar) issue using builds 264
(latest stable) and 273 (latest unstable) with the .NET 4 lightweight
client, regardless of caching configuration. The following test fails:

User u2;
bool happy;

using (var tx2 = new TransactionScope())
using (var s2 = store.OpenSession())
{
u2 = new User {Username = "b", Email = "b@b"};
s2.Store(u2);
s2.SaveChanges();
tx2.Complete();
}

using (var s3 = store.OpenSession())
{
s3.Advanced.AllowNonAuthoritiveInformation = false;
happy = s3.Load<User>(u2.Id) != null;
}

Assert.IsTrue(happy);

However, the test passes when using an embedded instance (in both
builds). I have tried with DTC both started and stopped.
Interestingly, I see the PUT as expected in the console output when
running in debug mode, but I do not see the POST to bulk_docs, nor do
I see the document in the web UI.

Do I need to perform more configuring for ambient TransactionScopes to
be respected? Perhaps there is a bug?

Thanks in advance.

-Mike

> ...
>
> read more »