I imagine the following WCF service usage: (of a cash acceptor)
Service Consumer 1 Service Consumer 2
cashAcceptorService.BeginTransaction(); cashAcceptorService.StopDevice();
//this should throw exception: device is locked / used in a transaction
cashAcceptorService.AcceptMoney();
cashAcceptorService.EndTransaction();
Service Consumer 1 and 2 use the same WCF single instance. I wonder if this functionality is already implemented. Do WCF transactions offer this?
How do you see this done?
If the following is true:
The service is interacting with a transactional object (eg the database)
The service has transaction flow enabled
Then WCF does indeed offer this.
The client can then use the TransactionScope class. Any transactions initiated on the client will flow through to the service automatically.
using(TransactionScope transactionScope = new TransactionScope())
{
// Do stuff with the service here
cashAcceptorService.AcceptMoney();
//
//
transactionScope.Complete();
}
Handling transactions in WCF tends to be an entire chapter of a book, but this should be enough information to get you on the right track.
It is always better to understand the concept of distributed transactions . I recommend to read this article http://www.codeproject.com/Articles/35087/Truly-Understanding-NET-Transactions-and-WCF-Imple
Related
My WCF service method needs to perform concurrent tasks in a transaction which is flowed from the client to service. To enable a transaction scope to flow through threads, I enabled the TransactionScopeAsyncFlowOption in the constructor of transaction scope class before sending call to service.
using (var transaction = new TransactionScope(TransactionScopeAsyncFlowOption.Enabled))
{
//service call here. Async flow option has no effect on service side.
}
The transaction flows from client to service but it is not able to flow to sub tasks. If, however, I create new transaction scope in the service and enable its async flow there, then transaction flows to sub tasks. So my question is, why the TransactionScopeAsyncFlow option has no effect on the transaction at the service end? Should not it take the client transaction scope settings so there would not be any need to create new transaction scope in service just to enable its async flow?
I found similar question here as well. What actually happens is that WCF loses nearly all of its context upon crossing the threshold of first await and we should explicitly opt-in to flow any ambient context such as ambient transaction to subsequent async calls. There are some workarounds mentioned in this book. Check them out if you need more detail. I'll go with creating new scope before async call in the service operation.
I am having a WCF service which is configured for TransactionScopeRequired = true. It performs following actions.
1) Receives message from the transactional queue
2) Open a transaction scope(new transactionScope()) with in the Service Operation
3. Calla Java Webservice
4) Send results to a transactional queue.
While sending message to a transactional queue it is throwing error "Cannot enlist transaction".
Could anyone please guide me on this?
Thanks
Rakesh
The absence of details (e.g. service and client binding configuration) makes providing a specific response/guidance difficult.
In terms of general guidance, you may want to enable WCF Tracing and Message Logging, which will allow you to monitor/review the WCF transactions and hopefully discover additional information about the issue.
The following links provide a good overview:
http://msdn.microsoft.com/en-us/library/ms733025.aspx
So I have been tasked with setting up MSMQ so that if our mail server goes down (which is seems to often) the messages just end up in the Queue and will be delivered when they come back up. With that said I have to say I don't know much about this except what I have learned in the past 24 hours however I believe I know enough to take the right approach but I wanted to ask someone in the community because there is some confusion amongst my colleagues given some existing setup in our WCF application.
Currently we have some services that use msmq as the protocol for the endpoint. the endpoint looks like this
<endpoint address="net.msmq://localhost/private/Publisher"
behaviorConfiguration="BatchBehaviour"
binding="netMsmqBinding"
bindingConfiguration="MSMQNoSecurity"
contract="HumanArc.Compass.Shared.Publisher.Interfaces.Service.IPublisherSubscriber"
name="PublishSubscriber"/>
This of course lets the client make a service call and if for some reason the service wasn't up it will ensure that when the service comes back up the call will be processed. What I don't think that it will do is if you have something like the following in you service method.
try
{
smtp.Send(mail);
return true;
}
catch (System.Net.Mail.SmtpFailedRecipientException ex)
{
throw new Exception("User Credentials for sending the Email are Invalid",ex);
}
catch (System.Net.Mail.SmtpException smtpEx)
{
throw new Exception(string.Format("Application encountered a problem send a mail message to {0} ", smtpHostName),smtpEx);
}
WCF isn't going to retry and send the message again somehow, am I correct about this assumption?
What I think we should have is something that looks like the following in place of the call to smtp.send() above. (from http://www.bowu.org/it/microsoft/net/email-asp-net-mvc-msmq-2.html)
string queuePath = #".\private$\WebsiteEmails";
MessageQueue msgQ;
//if this queue doesn't exist we will create it
if(!MessageQueue.Exists(queuePath))
MessageQueue.Create(queuePath);
msgQ = new MessageQueue(queuePath);
msgQ.Formatter = new BinaryMessageFormatter();
msgQ.Send(msg);
Then somewhere in the startup of the service (I am not sure where yet) we set up an event handler that will actually call send() on the SmtpClient object. Something like this
msgQ.ReceiveCompleted += new ReceiveCompletedEventHandler(msgQ_ReceiveCompleted)
So to sum it all up my first question is which way is better? Create a service that uses net:msmq as the protocol or just change the email method to put messages in the queue and set up a handler for it? The next question, if my assumption about changing the method that calls SmtpClient.Send() is correct then where in the program should I wire up ReceiveCompleted? Out WCF service is hosted in a windows service, meaning there is actually a call to ServiceBase.Run(servicesToRun). Is there a place I could wire it up there? My experience with WCF is with much simpler IIS hosted services so I am not 100% sure.
Thanks - I realize this is a long question but I have been trying to research it and there is a lot of information and I can't seem to find a clear explanation of the benefits of doing things one way vs another.
Your approach to using msmq to address availability in a downstream dependency (in this case your smtp server) is valid. However, there are a couple of things you should understand about msmq first.
If you create a queue in msmq then by default it is non-transactional. In this mode the queue will not provide the kind of guaranteed delivery semantic you require. So create your queues as transactional.
Then you can tell WCF that your service operation will enlist in the transaction when it receives a message for processing. You do this by defining a behavior on your service operation implementation:
[OperationBehavior(TransactionScopeRequired = true, TransactionAutoComplete = true)]
public void SendEmail(Something mail)
{
....
smtp.Send(mail);
}
TransactionScopeRequired tells WCF that the service operation should enlist in the same transaction used to transmit the message from sender to receiver. TransactionAutoComplete states that the service method should commit the transaction once the operation has successfully completed. So in answer to your query above, a failure in the service operation will cause the transaction to rollback.
What happens at this point depends on your service bindings configuration.
<netMsmqBinding>
<binding name="netMsmqBinding_IMyServiceInterface"
exactlyOnce="true"
maxRetryCycles="3"
retryCycleDelay="00:01:00"
receiveErrorHandling="Move"> <-- this defines behavior after failure
...
</binding>
</netMsmqBinding>
When, for whatever reason the transaction is not committed (for example, an unhandled exception occurs), WCF will roll the message back onto the queue and retry processing once per minute up to 3 times (defined by maxRetryCycles and retryCycleDelay).
If the message still fails processing after this time then the receiveErrorHandling attribute tells WCF what to do next (The above binding specifies that the message be moved to the system poison message queue).
Note: exactlyOnce tells WCF that we require transactions, that each message will be delivered exactly once and in the order they were sent.
So your original approach is in fact correct and you just need to configure your service correctly to implement the behavior you want.
I have WCF Per-Call service which provides data for clients and at the same time is integrated with NServiceBus.
All stateful objects are stored in UnityContainer which is integrated into custom service host.
NServiceBus is configured in service host and uses same container as service instances.
Every client has its own instance context(described by Juval Lowy in his book in chapter about Durable Services).
If I need to send request over bus I just use some kind of dispatcher and wait response using Thread.Sleep().Since services are per-call this is ok afaik.
But I am confused a bit about messages from bus, that service must handle and provide them to clients. For some data like stock quotes I just update some kind of stateful object and and then, when clients invoke GetQuotesData() just provide data from this object.
But there are numerous service messages like new quote added and etc.
At this moment I have an idea to implement something like "Postman daemon" =)) and store this type of messages in instance context. Then client will invoke "GetMail()", receive those messages and parse them. Problem is that NServiceBus messages are "Interface based" and I cant pass them over WCF, so I need to convert them to types derived from some abstract class.
I Don't know what is best way to handle this situation.
Have you considered a "pure" NServiceBus solution for communicating back to clients? NServiceBus already has that "Postman daemon" capability. NServiceBus messages don't have to be interfaces - you can use regular classes as well.
Hope that helps.
I have a WCF logging service that runs operates over MSMQ. Items are logged to a Sql Server 2005 database. Every functions correctly if used outside a TransactionScope. When used inside a TransactionScope instance the call always causes the transaction to be aborted. Message = "The transaction has aborted".
What do I need to do to get this call to work inside a Transaction? Is it even possible. I've read that for a client transaction to flow across a service boundary the binding must support transaction flow, which immediately limits the bindings to only NetNamedPipeBinding, NetTcpBinding, WSHttpBinding, WSDualHttpBinding and WSFederationHttpBinding.
I'm not intimately knowledgeable about MSMQ, but there's a really good blog post series by Tom Hollander on MSMQ, IIS and WCF: Getting them to play nicely - in part 3 which is the link provided Tom talks about getting transactional.
MSMQ can be transactional - or not. And in WCF, you can decorate both the service contract as well as individual operation contracts (methods) with transaction-related attributes, such as whether to allow, disallow, or require a transaction context.
As far as I understand, in your setup, you don't want the MSMQ part to be transactional - but you should be able to use it even if an ambient transaction is present. In this case, you need to add the TransactionFlow="ALlowed" to your operation contract like this:
[ServiceContract]
public interface ILoggingService
{
[OperationContract]
[TransactionFlow(TransactionFlowOption.Allowed)]
void LogData(......);
}
That should do it!
Marc
Sorry for the needless question...
I have solved my problem. I needed to place
[TransactionFlow(TransactionFlowOption.Allowed)]
on the operation in the service contract and then
[OperationBehavior(TransactionScopeRequired=true)]
on the implementation of the contract (the service itself).
Works a treat.