I have a Windows Service Application
in which i create WCF services in it.
One of the services is data
services: add, delete,
read , updatte data via
WCF.
WCF use NHibernate for data manipulation
So my guestions are:
Any advice (best practice) for session management for Hibernate using with WCF?
Anybody knows anything about
WcfOperationSessionContext (hibernate 3.0) class?
how to use it with WCF?
Well to make it concrete :
Suppose that i have WCF Service called DataServices
class WCFDataService .....
{
void SaveMyEntity(MyEntity entity)
{
.....................?? // How to do? Best Way
// Should i take one session and use it all times
// Should i take session and dipsose when operation finished then get
//new session for new operations?
// If many clients call my WCF service function at the same time?
// what may go wrong?
// etc....
}
}
And I need a NHibernateServiceProvider class
class NHibernateServiceProvider ....
{
// How to get Session ?? Best way
ISession GetCurrentSession(){.... }
DisposeSession(){ ....}
}
Best Wishes
PS: I have read similiar entries here and other web pages. But can not see "concrete" answers.
The WcfOperationSessionContext, similar to ThreadStaticSessionContext and WebRequestSessionContext is an implementation for a session context. The session context is used to bind (associate) a ISession instance to a particular context.
The session in the current context can be retrieved by calling ISessionFactory.GetCurrentSession().
You can find more information about session context here.
The WcfOperationSessionContext represents a context that spans for the entire duration of a WCF operation. You still need to handle the binding of the session in the begining of the operation and the unbinding/commiting/disposal of the session at the end of the operation.
To get access to the begin/end actions in the wcf pipeline you need to implement a IDispatchMessageInspector. You can see a sample here.
Also regarding WCF integration: if you use ThreadStatic session context it will appear to work on development, but you will hit the wall in production when various components (ex: authorization, authentication ) from the wcf pipeline are executed on different threads.
As for best practices you almost nailed it: Use WcfOperationSessionContext to store the current session and the IDispatchMessageInspector to begin/complete your unit of work.
EDIT - to address the details you added:
If you configured WcfOperationSessionContext and do the binding/unbinding as i explained above, all you have to do to is inject the ISessionFactory into your service and just use factory.GetCurrentSession(). I'll post a sample prj if time permits.
Here is the sample project
The model we use for managing NHibernate sessions with WCF is as follows:
1) We have our own ServiceHost class that inherits from System.ServiceModel.ServiceHost which also implements ICallContextInitializer. We add the service host instance to each of the operations in our service as follows:
protected override void InitializeRuntime()
{
base.InitializeRuntime();
foreach (ChannelDispatcher cd in this.ChannelDispatchers)
{
foreach (EndpointDispatcher ed in cd.Endpoints)
{
foreach (DispatchOperation op in ed.DispatchRuntime.Operations)
{
op.CallContextInitializers.Add(this);
}
}
}
}
public void AfterInvoke(object correlationState)
{
// We don't do anything after the invoke
}
public object BeforeInvoke(InstanceContext instanceContext, IClientChannel channel, Message message)
{
OperationContext.Current.Extensions.Add(new SessionOperationContext());
return null;
}
The BeforeInvoke simply makes sure that the OperationContext for each WCF call has it's own session. We have found problems with IDispatchMessageInspector where the session is not available during response serialisation - a problem if you use lazy loading.
2) Our SessionOperationContext will then be called to attach itself and we use the OperationCompleted event to remove ourselves. This way we can be sure the session will be available for response serialisation.
public class SessionOperationContext : IExtension<OperationContext>
{
public ISession Session { get; private set; }
public static SessionOperationContext Current
{
get
{
OperationContext oc = OperationContext.Current;
if (oc == null) throw new InvalidOperationException("Must be in an operation context.");
return oc.Extensions.Find<SessionOperationContext>();
}
}
public void Attach(OperationContext owner)
{
// Create the session and do anything else you required
this.Session = ... // Whatever instantiation method you use
// Hook into the OperationCompleted event which will be raised
// after the operation has completed and the response serialised.
owner.OperationCompleted += new EventHandler(OperationCompleted);
}
void OperationCompleted(object sender, EventArgs e)
{
// Tell WCF this extension is done
((OperationContext)sender).Extensions.Remove(this);
}
public void Detach(OperationContext owner)
{
// Close our session, do any cleanup, even auto commit
// transactions if required.
this.Session.Dispose();
this.Session = null;
}
}
We've used the above pattern successfully in high-load applications and it seems to work well.
In summary this is similar to what the new WcfOperationSessionContext does (it wasn't around when we figured out the pattern above;-)) but also overcomes issues surrounding lazy loading.
Regarding the additional questions asked: If you use the model outlined above you would simply do the following:
void SaveMyEntity(MyEntity entity)
{
SessionOperationContext.Current.Session.Save(entity);
}
You are guaranteed that the session is always there and that it will be disposed once the WCF operation is completed. You can use transactions if required in the normal way.
Here is a post describing, in detail, all the steps for registering and using the WcfOperationSessionContext. It also includes instructions for using it with the agatha-rrsl project.
Ok, after few days of reading internet posts etc. all approaches shown in the internets seems to be wrong. When we are using UnitOfWork pattern with NH 3^ with nhibernate transaction this all aprochaes are producing exceptions. To test it and proof that we need to create test enviroment with MSMQ transaction queue, special interface with OneWay operation contract with transaction required set on it. This approach should works like this:
1. We put transactionally message in queue.
2. Service is getting transactionally messege from queue.
3. Everything works queue is empty.
In some cases not so obious with internet approaches this does not work properly. So here are expamples which we tested that are wrong and why:
Fabio Maulo approach: Use ICallContextInitializer - open NH session/transaction on BeforeCall, after that WCF is executing service method, on AfterCall in context initializer we call session.Flush + transaction.commit. Automaticly session will be saved when transaction scope will commit operation. In situation when on calling transaction.Complete exception will be thrown WCF service will shutdown! Question can be ok, so take transaction.Complete in try/catch clausule - great! - NO wrong! Then transaction scope will commit transaction and message will be taken from queue but data will not be saved !
Another approach is to use IDispatchMessageInspector - yesterday I thought this is best approach. Here we need to open session/transaction in method AfterReceiveRequest, after WCF invoke service operation on message dispatcher inspector BeforeSendReply is called. In this method we have info about [reply] which in OneWay operation is null, but filled with fault information if it occured on invoking service method. Great I thought - this is this ! but NOT! Problem is that at this point in WCF processing pipe we have no transaction ! So if transaction.Complete throw error or session.Flush will throw it we will have not data saved in database and message will not come back to queue what is wrong.
What is the solution?
IOperationInvoker and only this!
You need to implement this interface as a decorator pattern on default invoker. In method Invoke before call we are openning session/transaction open then we call invoke default invoker and after that call transaction.complete in finally clausule we call session.flush. What types of problem this solves:
1. We have transaction scope on this level so when complete throws exception message will go back to queue and WCF will not shutdown.
2. When invocation will throw exception transaction.complete will not be called what will not change database state
I hope this will clear everyones missinformation.
In some free time I will try to write some example.
Related
As a follow-up to this question, I wanted to understand how my invoking of a Service manually can be improved. This became longer than I wanted, but I feel the background info is needed.
When doing a pub/sub (broadcast), the normal sequence and flow in the Messaging API isn't used, and I instead get a callback when a pub/sub message is received, using IRedisClient, IRedisSubscription:
_subscription.OnMessage = (channel, msg) =>
{
onMessageReceived(ParseJsonMsgToPoco(msg));
};
The Action onMessageReceived will then, in turn, invoke a normal .NET/C# Event, like so:
protected override void OnMessageReceived(MyRequest request)
{
OnMyEvent?.Invoke(this, new RequestEventArgs(request));
}
This works, I get my request and all that, however, I would like it to be streamlined into the other flow, the flow in the Messaging API, meaning, the request finds its way into a Service class implementation, and that all normal boilerplate and dependency injection takes place as it would have using Messaging API.
So, in my Event handler, I manually invoke the Service:
private void Instance_OnMyEvent(object sender, RequestEventArgs e)
{
using (var myRequestService = HostContext.ResolveService<MyRequestService>(new BasicRequest()))
{
myRequestService.Any(e.Request);
}
}
and the MyRequestService is indeed found and Any called, and dependency injection works for the Service.
Question 1:
Methods such as OnBeforeExecute, OnAfterExecute etc, are not called, unless I manually call them, like: myRequestService.OnBeforeExecute(e) etc. What parts of the pipeline is lost? Can it be reinstated in some easy way, so I don't have to call each of them, in order, manually?
Question 2:
I think I am messing up the DI system when I do this:
using (var myRequestService = HostContext.ResolveService<MyRequestService>(new BasicRequest()))
{
myRequestService.OnBeforeExecute(e.Request);
myRequestService.Any(e.Request);
myRequestService.OnAfterExecute(e.Request);
}
The effect I see is that the injected dependencies that I have registered with container.AddScoped, isn't scoped, but seems static. I see this because I have a Guid inside the injected class, and that Guid is always the same in this case, when it should be different for each request.
container.AddScoped<IRedisCache, RedisCache>();
and the OnBeforeExecute (in a descendant to Service) is like:
public override void OnBeforeExecute(object requestDto)
{
base.OnBeforeExecute(requestDto);
IRedisCache cache = TryResolve<IRedisCache>();
cache?.SetGuid(Guid.NewGuid());
}
So, the IRedisCache Guid should be different each time, but it isn't. This however works fine when I use the Messaging API "from start to finish". It seems that if I call the TryResolve in the AppHostBase descendant, the AddScoped is ignored, and an instance is placed in the container, and then never removed.
What parts of the pipeline is lost?
None of the request pipeline is executed:
myRequestService.Any(e.Request);
Is physically only invoking the Any C# method of your MyRequestService class, it doesn't (nor cannot) do anything else.
The recommended way for invoking other Services during a Service Request is to use the Service Gateway.
But if you want to invoke a Service outside of a HTTP Request you can use the RPC Gateway for executing non-trusted services as it invokes the full Request Pipeline & converts HTTP Error responses into Typed Error Responses:
HostContext.AppHost.RpcGateway.ExecuteAsync()
For executing internal/trusted Services outside of a Service Request you can use HostContext.AppHost.ExecuteMessage as used by ServiceStack MQ which applies Message Request Request/Response Filters, Service Action Filters & Events.
I have registered with container.AddScoped
Do not use Request Scoped dependencies outside of a HTTP Request, use Singleton if the dependencies are ThreadSafe, otherwise register them as Transient. If you need to pass per-request storage pass them in IRequest.Items.
Hello i am trying to do a trail log for some of my API endpoints.These logs are generated when the endpoint is called.I would like the writing of the logs to be done in an asynchrouns manner (as lightweight as possible) as to not affect the performance of my usual logic.
I was thinking to have a component that is injectable and can be called anywhere in my endpoints when a log is produced.The problem is that i seem to not find a suitable async solution:
Important service that needs not be obstructed by delays
public interface IImportantInterface
{
Task DoSomethingUndistrubedAsync(string value);
}
**Wrapper around Redis pub-sub**
public interface IIOService{
Task PublishAsync( object obj);
}
Controller
public class Controller
{
private IImportantInterface importantService;
private Publisher publisher;
[HttpPost]
public async Task SomeEndpointAsync(){
this.publisher.Publish([some_log]);
await this.importantService.DoSomethingUndisturbedAsync([something]);
}
public Controller(IImportantInterface importantService)
{
this.importantService=importantService;
}
}
Now comes the real problem.How do i make the smallest footprint for my Publisher.I came up with 3 scenarios but two of them are unfeasible due to going out of scope:
Attempt 1
Transient Service with Task scoped to method:
public class Publisher{
private IIOService writeService{get;set;}
public async Task PublishAsync(object obj){
Task t1=Task.Run(async()=>await writeService.PublishAsync(obj)); //t1 might not finished when method exits
}
}
Task t1 might not finish by the time the method ends.
Attempt 2
Task embedded in Transient Service
public class Publisher{ //publisher might get discarded when calling controller gets out of scope
private Task t1;
private IIOService writeService{get;set;}
public async Task PublishAsync(object obj){
t1=Task.Run(async ()=> this.IIOService.writeService(obj));
}
}
Now task will not get collected after method scope , but it might not finish by the time the calling Controller method class gets out of scope
Attempt 3
Singleton object with a ConcurrentQueue of Tasks that get enqueued.
This would not get out of scope but when would i clear the items?
public class Publisher{
private ConcurrentQueue<Task> Queue;
public async Task PublishAsync(object obj){
this.Queue.Enqueue();
}
}
P.S I want to publish these logs in a common place.From that place the target is to get published to a Redis database using the pub-sub functionality.
Should i just write to Redis ?
Hello i am trying to do a trail log for some of my API endpoints.These logs are generated when the endpoint is called.I would like the writing of the logs to be done in an asynchrouns manner (as lightweight as possible) as to not affect the performance of my usual logic.
I strongly recommend that you use an existing and exhaustively-tested logging library, of which there are many with modern capabilities such as semantic logging and async-compatible implicit state.
Modern logging libraries generally have a singleton kind of design, where logs are kept in-memory (and logging methods are synchronous). Then there is a separate "processor" which publishes these messages to a collector. If you insist on writing your own logging framework (why?), I would recommend you take the same approach as all the other highly successful logging frameworks.
I have a WCF service and I have the following (simplified) class:
public class PerOperationSingleton : IDisposable
{
private static bool _hasInstance = false;
public PerOperationSingleton()
{
if(_hasInstance)
throw new InvalidOperationException("Cannot have multiple instances during a single WCF operation");
_hasInstance = true;
}
public void Dispose()
{
_hasInstance = false;
}
}
I guess, it's pretty self explanatory piece of code. I don't need a singleton for entire WCF service but only during a single operation call. If one instance of the PerOperationSingleton is disposed, it should be safe to create a new instance during the same WCF operation.
The problem is that I don't know how to make the _hasInstance variable to be effective only for one WCF operation. I know about [ThreadStatic], but I've heard that ASP.NET and WCF do not guarantee that an operation will be executed on a single thread - it might be transferred to another thread.
I definitely don't want my _hasInstance = true to move to thread pool and get incorrectly detected if some other operation picks that thread from the pool.
If WCF operation moves to another thread, I would like the _hasInstance variable to keep the "true" value if it was set.
And I don't want to change some global settings for my WCF service to avoid affecting the performance or get into some problems which will be hard to debug and solve later (I don't feel proficient enough in advanced ASP.NET and WCF topics).
I cannot store _hasInstance in session either because my client requested to disable .NET sessions for various reasons.
I would like the class PerOperationSingleton actually to be environment agnostic. It shouldn't really know anything about WCF or ASP.NET.
How do I make _hasInstance variable static during entire call of my WCF operation and don't affect other WCF operations?
I would consider using OperationContext to make you data "static" during the operation call.
Here is a similar discussion Where to store data for current WCF call? Is ThreadStatic safe?
I have a WCF Service, hosted inside of IIS, using NHibernate for data access.
In my Global.asax I configure NHibernate on Application_Start. This means that I only perform the expensive task of setting up all of the mappings once for my WCF Service.
The only problem with this is that if the database was unavailable during start up, the mappings will never get set up (as they will have failed to be set up during Application_Start and the event won't be called again until the app pool is recycled).
How can I handle the NHibernate set up so it occurs only once, except where there is an error (such as the database not being available) in which case it will occur on each request until it works?
What you need is a Lazy Singleton to be your SessionFactory. You call a method to get the session factory and it checks if the session already exists. So the expensive task of creating the Session Factory is done the first time someone needs it.
You could do something like this:
public ISessionFactory GetSessionFactory()
{
// sessionFactory is STATIC
if (sessionFactory == null)
{
global::NHibernate.Cfg.Configuration cfg = new NHibernateConfigurationFactory(CurrentConfiguration).GetConfiguration(sessionFactoryName);
// Now that we have our Configuration object, create a new SessionFactory
sessionFactory = cfg.BuildSessionFactory();
if (sessionFactory == null)
{
throw new InvalidOperationException("cfg.BuildSessionFactory() returned null.");
}
}
return sessionFactory;
}
A complete solution is available here:
NHibernate - good complete working Helper class for managing SessionFactory/Session
I am throwing this answer into the mix in order to get comments on it - this answer was emailed to me, but I'd appreciate the view of the SO community before I decide on the final solution...
Rather than using the Application_Start event, use the Begin_Request event. Store the NHibernate session in a field and in the Begin_Request event, check if the field is null and if it is, create the NHibernate session (otherwise, continue to use the one already created).
So essentially, this would mean moving the create logic into a method I can call from Begin_Request in the event of "detecting that the session hasn't yet been created".
I'm trying to learn WCF to use it as an IPC mechanism for a host/plugin system. The host needs to be able to call the plugin to Start/Stop it, and the plugin needs to call the server back to perform logging.
I made a simple test case where the host creates an endpoint on net.pipe://localhost/SampleServer with the following ServiceContract:
[ServiceContract]
public interface IWcfServer
{
[OperationContract]
void Log(string message);
}
And the plugin creates an endpoint on net.pipe://localhost/SampleClient with the following ServiceContract:
[ServiceContract]
public interface IWcfClient
{
[OperationContract]
string Init();
}
Here's a sample of how I'm setting up each endpoint:
this.server = new ServiceHost(this);
this.server.AddServiceEndpoint(typeof(IWcfServer),
new NetNamedPipeBinding(),
"net.pipe://localhost/SampleServer");
this.server.Open();
And here's a sample of how I'm making the calls:
ChannelFactory<IWcfClient> factory = new ChannelFactory<IWcfClient>(
new NetNamedPipeBinding(),
new EndpointAddress("net.pipe://localhost/SampleClient"));
IWcfClient client = factory.CreateChannel();
using ((IClientChannel)client)
{
client.Init());
}
I already confirmed that the host can call plugin.Init(), and the plugin can call host.Log(message) without issues. However, if this following scenario happens:
Host calls plugin.Init()
During the execution of plugin.Init(), the plugin attempts to call host.Log(message)
The applications freezes, and I get a TimeoutException after 1min. Anyone has any ideas on what I'm doing wrong?
what is the InstanceContextMode of the service host ? If it is a singleton, it will block until Init() returns - resulting in a circular dependency.
1 min is the standard wcf timeout.
Do you have a circular reference?
Also, why do you have 2 contracts, when you make a call to client.init who is listening?
Turn on E2E tracing for WCF to check what exactly is timing out. - http://msdn.microsoft.com/en-us/library/ms733025.aspx. Besides your methods might be causing a deadlock since init might require log and log might require init to happen first or something like that.
"net.pipe://localhost/SampleServer"
"net.pipe://localhost/SampleClient"
You have two different URL for the Server and for the Client. It is a problem!