Tagged: wcf

Creating stronger value type contracts

I’ve long been annoyed that value types don’t have strong semantic information attached to them such that the compiler would barf if I try and pass an value type that isn’t semantically the same as what the function wanted. For example, what does the following signature mean other than than taking in 2 ints and returning a bool?

IsLoggedIn :: int -> int -> bool

What I’d really like the signature to look like is

IsLoggedIn :: UserId -> SessionId -> bool

In F# you can do this sort of with type aliases and augmenting the signature with the type information. However, its just editor magic, it doesn’t actually compile to anything that would stop you from accidentally calling a function with the arguments reversed. An int is an int is an int, right?

var userId = 1
var sessionId = 2

IsLoggedIn(sessionId, userId)

This is perfectly valid to the … Read more

wcf Request Entity Too Large

I ran into a stupid issue today with WCF request entity too large errors. If you’re sure your bindings are set properly on both the server and client, make sure to double check that the service name and contract’s are set properly in the server.

My issue was that I had at some point refactored the namespaces where my service implementations were, and didn’t update the web.config. For the longest time things continued to work, but once I reached the default max limit (even though I had a binding that set the limits much higher), I got the 413 errors.

So where I had this:

<service name="Foo.Bar.Service">
	<endpoint address="" binding="basicHttpBinding" bindingConfiguration="LargeHttpBinding" contract="Foo.Bar.v1.Service.IService"/>

I needed

<service name="Foo.Bar.Implementation.Service">
	<endpoint address="" binding="basicHttpBinding" bindingConfiguration="LargeHttpBinding" contract="Foo.Bar.v1.Service.IService"/>

How WCF managed to work when the service name was pointing to a non-existent class, I have no idea. But it did.… Read more

Flyweight Locking

Locking is a necessary aspect of multithreading code: it prevents unpredictable behavior and makes sure code that is expected to run synchronously does so. Some situations can leverage lockless code, but not always. When you do need to do a lock you shouldn’t do it carelessly, if you lock a section of code that does some major work (such as database access) and it blocks other pending calls you need to be cognizant that there could be a delay or bottleneck. However, just because we have to lock doesn’t mean we can’t do some simple optimizations depending on what our business logic is. If we only need to lock items per a defined group then we can leverage flyweight locking. Lets go through an example to make this scenario clearer.

Imagine we have a WCF service that signs a student into a class where the student has a name, an … Read more