sharing Repository classes between web mvc classes & wcf services

[costa]

Hello:

I currently have some functionality in a .net mvc 3 web app that I
want to expose through a wcf service.

I have a lot of Repository classes that ultimately use the
WebSessionStorage to get the nhibernate session. When the same code is
invoked from the web service the app barfs because, of course, there
HttpContext is null.

I noticed that there is a WcfSessionStorage but I am not too sure it
is going to work. In my mind I need a storage that makes my Repository
classes work in both scenarios and that would check both contexts.

Is there any pattern that I can use? I am on S#arpArchitecture 1.9.x.

Thanks

[Jonathan George]

If you're hosting the WCF service in the web app, then you probably want to enable ASP.NET compatibility mode (Google it) which will tie in the HTTP pipeline and should mean you can continue using WebSessionStorage (not tested this, please correct me if I'm wrong.)

Otherwise you should use the WcfSessionStorage. You can see an example of this in the Northwind project (Northwind.Wcf and Northwind.Wcf.Web) - note that your .svc needs to reference the Sharp Arch ServiceHostFactory instead of the standard WCF one.

The latter is the purist way of doing it, but the former should work.

Regards

Jon

--
You received this message because you are subscribed to the Google Groups "S#arp Architecture" group.
To post to this group, send email to sharp-arc...@googlegroups.com.
To unsubscribe from this group, send email to sharp-architect...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sharp-architecture?hl=en.

[costa]

Thanks, Jonathan. After I posted the message I found the compatibility
flag, and yes it works.

Here is what I did:

In web.config:

<system.serviceModel>
<serviceHostingEnvironment multipleSiteBindingsEnabled="true"
aspNetCompatibilityEnabled="true"/>
</system.serviceModel>

In the service class:

[AspNetCompatibilityRequirements(RequirementsMode =
AspNetCompatibilityRequirementsMode.Required)]
public class WcfService: IWcfService
{
...
}

I will also explore the other option...

Thanks

[costa]

I run into another interesting problem which is somewhat related to
this. I wanted to use the Parallel class to process some list elements
in parallel. However, the item processing function needed some data
from the database and obviously it failed to get it because there was
no HttpContext on the threads that the Parallel class used.

I think I am going to give up the Parallel class. In the end it won't
save me much time.

This let's me think about the entire model of getting sessions. In the
Java word there was the concept of connection pools and they always
worked no matter what thread you were on. Your responsibility was to
release the connection though to the connection pool.

I personally think that the current model that S#arp architecture uses
to get connections(sessions) to the database needs to be rethought.

[Jonathan George]

See http://stackoverflow.com/questions/242961/nhibernate-session-and-multithreading and various other places. Basically, the web model is based on having a single session for the web request. Because sessions aren't thread safe we'd need a completely different model for the multithreaded scenario, in which we could a) provide a different mechanism for accessing the session, and b) provide a different session for each thread. I'm sure this is achievable, but I'd question how necessary it is. 

If you're reading from the session, you'd probably get better performance by using Future queries - i.e. rather than having multiple, parallel requests to the DB, ensure you have a single request that gets all the data you need. And the same is true for writes - I would expect to see better perf from batching writes than from doing lots of individual parallel writes. This is all off the top of my head though, so I'd be interested in your specific scenario if you'd like to give more detail.

Cheers

Jon

[Alec Whittington]

The NHibernate session is not thread-safe by design. As it points out in the SO thread, as long as you open a session and use it on a single thread, you will be fine. I also don't think your running into issues with S# as this framework has been in use since 2009. We follow very well documented NHibernate session management practices. We do have some room for improvement, but not in the area of session management, more in the area of session storage.

With that said, there is nothing preventing you from micro-managing the NHibernate Session directly or using your own. All of it is extensible.

Alec Whittington

Owner - Webmaster / Developer

http://www.streetsource.com