Ayende @ Rahien

Ayende Rahien commented on Managing RavenDB Document Store startup

Tue, 11 Dec 2012 09:22:48 GMT

JT, Actually, the assumption here is that you have a separate connection string defined for each url, and the connection string name is the url.

JT commented on Managing RavenDB Document Store startup

Mon, 10 Dec 2012 17:45:19 GMT

Since you're using the ConnectionStringName property shouldn't you hand in a connection string name, not the Url? Or does ConnectionStringName support both? I thought Url would be used in the scenario of handing in the connection strings value.

configurator commented on Managing RavenDB Document Store startup

Sat, 08 Dec 2012 15:06:35 GMT

I was referring to the single store case. As for predicting when it will execute, it's easy enough to control by using RuntimeHelpers.RunClassConstructor. The only real problem with this sort of thing is exception handling - retrying once the constructor returned is not an option.

Ayende Rahien commented on Managing RavenDB Document Store startup

Fri, 07 Dec 2012 05:45:52 GMT

Configurator, There are a few problems with that, in particular, you can only have one of them. For another, it is actually quite hard to predict WHEN it will execute.

configurator commented on Managing RavenDB Document Store startup

Thu, 06 Dec 2012 22:46:41 GMT

Of course, I meant to remove those lines. public static class Global { public static readonly DocumentStore; Global() { DocumentStore = new DocumentStore { ConnectionStringName = "RavenDB" }; DocumentStore.Initialize(); } }

configurator commented on Managing RavenDB Document Store startup

Thu, 06 Dec 2012 22:43:36 GMT

Why not use a static constructor? They're very simple, and guaranteed by the framework to only be called once. public static class Global { private static readonly Lazy theDocStore = new Lazy(()=> { var docStore = new DocumentStore { ConnectionStringName = "RavenDB" }; docStore.Initialize(); //OPTIONAL: //IndexCreation.CreateIndexes(typeof(Global).Assembly, docStore); return docStore; }); public static readonly DocumentStore; Global() { DocumentStore = new DocumentStore { ConnectionStringName = "RavenDB" }; DocumentStore.Initialize(); } }

Alexei K commented on Managing RavenDB Document Store startup

Wed, 05 Dec 2012 14:42:01 GMT

While a nice way of doing things for a project with external db, it's most certainly not the "correct" way to do it if you have an embedded db. In this scenario you don't want to delay db initialization to first use, because it creates visible delay to the user. You want to start db init right away in a separate Task, e.g.: dbLoader = Task.Factory.StartNew(() => BaseViewModel.LoadDocumentStore()); and then have accessor property for your db return dbLoader.Result. Chances are db might not be fully up by the time of first query (so there might still be some delay), but at least you've cut down on waiting.

Ayende Rahien commented on Managing RavenDB Document Store startup

Tue, 04 Dec 2012 22:32:56 GMT

Paul, This is one application (app domain) _accessing_ different servers.

Paul K commented on Managing RavenDB Document Store startup

Tue, 04 Dec 2012 22:25:25 GMT

AndersM, thanks -- makes sense now.

AndersM commented on Managing RavenDB Document Store startup

Tue, 04 Dec 2012 22:23:13 GMT

You are not sharing the instance between different servers. You are sharing several instances of DocumentStores (which point to different servers) in your application. The post is not very interesting for a web developer who only uses one instance of a documentstore.

Paul K commented on Managing RavenDB Document Store startup

Tue, 04 Dec 2012 21:51:49 GMT

What am I missing here? Even with a static class, how could you share the same instance across multiple servers and entirely different app domains?

Rafal commented on Managing RavenDB Document Store startup

Tue, 04 Dec 2012 18:35:18 GMT

Nice, but what happened to interesting posts?

Daniel Lang commented on Managing RavenDB Document Store startup

Tue, 04 Dec 2012 02:22:47 GMT

@Bill, like AndersM already said - what's the point of using it then?

Chris Marisic commented on Managing RavenDB Document Store startup

Mon, 03 Dec 2012 19:37:29 GMT

@Radenko of course. This is the practice I've followed for over 2 years in porduction.

AndersM commented on Managing RavenDB Document Store startup

Mon, 03 Dec 2012 18:26:08 GMT

If you use this in application_start there is no need for all of this - application_start is only run once.

Bill commented on Managing RavenDB Document Store startup

Mon, 03 Dec 2012 17:47:41 GMT

@Daniel, You can just use this class within application_start, and create your indexes there. Same functionality, with a nicely enclosed factory for your instances.

Ryan Heath commented on Managing RavenDB Document Store startup

Mon, 03 Dec 2012 16:22:37 GMT

No, thanks, we have an ioc container for this. No extra code needed at all ;) // Ryan

Josh Close commented on Managing RavenDB Document Store startup

Mon, 03 Dec 2012 16:21:40 GMT

This is what I always look at, from Jon Skeet. http://csharpindepth.com/articles/general/singleton.aspx

Daniel Lang commented on Managing RavenDB Document Store startup

Mon, 03 Dec 2012 14:50:34 GMT

I think I don't like this pattern. It defers the instantiation of the document store to when you actually want to access it. Usually, I want to catch errors early on (raven not available, cannot create indexes, etc.) and handle them gracefully. This becomes especially hard when you don't know exactly / don't see easily where the document store gets created.

Radenko Zec commented on Managing RavenDB Document Store startup

Mon, 03 Dec 2012 13:22:31 GMT

Can we just register it in our favorite IO container as singleton ?

njy commented on Managing RavenDB Document Store startup

Mon, 03 Dec 2012 13:04:29 GMT

@Chris: you're right, thanks

Patrick Huizinga commented on Managing RavenDB Document Store startup

Mon, 03 Dec 2012 12:48:43 GMT

*sigh* It seems I was partly wrong about the blocking part. I just looked at the decompiled sources of ConcurrentDictionary and TryAdd does always use a lock.

Patrick Huizinga commented on Managing RavenDB Document Store startup

Mon, 03 Dec 2012 12:36:59 GMT

Hmm I thought this blog supported at least the markdown for code blocks. Ah well, Chris Chilvers already posted a better reply anyway

Patrick Huizinga commented on Managing RavenDB Document Store startup

Mon, 03 Dec 2012 12:34:39 GMT

njy: GetOrAdd is equivalent to: if (!dict.TryGetValue() value = delegate() dict.TryAdd(value) return dict[key] So no guarantees your delegate will not be invoked if another delegate is already running. As far as I know no method in ConcurrentDictionary is blocking (except maybe in highly contended cases)

Chris Chilvers commented on Managing RavenDB Document Store startup

Mon, 03 Dec 2012 12:32:57 GMT

@njy The documentation for GetOrAdd(TKey, Func) says that the "valueFactory may be called multiple times". However, the ConcurrentDictionary does ensure that only one of the created values will be added to the dictionary and returned. If you created the IDocumentStore immediately you may create multiple of them. By using Lazy though, you create multiple lazily initiated document stores rather than multiple document stores. Only one of the lazy objects will be successful and make it in to the dictionary, so only one of them gets instantiated.

njy commented on Managing RavenDB Document Store startup

Mon, 03 Dec 2012 11:54:53 GMT

Oren, that wouldn't be taken care of by the GetOrAdd of the ConcurrentDictionary?

Ayende Rahien commented on Managing RavenDB Document Store startup

Mon, 03 Dec 2012 10:31:07 GMT

Itamar, Actually, there is an important reason to want to do that. Imagine that you have two calls to the same document store at the same instant. The Lazy reference make sure that only _one_ call will be made to the initialization function.

Itamar Syn-Hershko commented on Managing RavenDB Document Store startup

Mon, 03 Dec 2012 10:29:02 GMT

In the multiple doc-store scenario, the use of Lazy<> is redundant and pretty much useless. Once CreateDocumentStore is called you can just return the actual value and put it in the ConcurrentDictionary, no real value in wrapping this in Lazy<>. Note how you call .Value on it and are forcing evaluation and instantiation immediately after calling CreateDocumentStore anyway.