none
for WCF transaction, why I must close proxy before close the transactionscope? RRS feed

  • Question

  • Hi experts,

    In WCF, if it's a per-call service, I can close the transactionscope before close the proxy. And for a per-session service, I must close proxy before close the transactionscope. Can you please explain the underlying mechanism why I should do this in that sequence? Thanks in advance.

    Wednesday, May 20, 2015 3:49 AM

Answers

  • hi Samuel,
      As per this case, check the following details :
    Per-Call Transactional Service :
      As far as a per-call service call is concerned, transactional programming is almost incidental. Every call on the service gets a new instance, and that call may or may not be in the same transaction Regardless of transactions, in every call the service gets and saves its state from a resource manager, so the methods are always guaranteed to operate on consistent state from the previous transaction or on the temporary yet well-isolated state of the current transaction in progress. A per-call service must vote and complete its transaction in every method call. In fact, a per-call service must always use auto-completion

    Per-Session Transactional Service
      The default transaction configuration of WCF will turn any service, regardless of its instancing mode, into a per-call service. This behavior is geared toward consistency in the service state management, requiring the service to be state-aware. However, having a state-aware service negates the very need for a per-session service in the first place. WCF does allow you to maintain the session semantic with a transactional service. A per-session transactional service instance can be accessed by multiple transactions, or the instance can establish an affinity to a particular transaction, in which case, until it completes, only that transaction is allowed to access it.

    for more information, Click here to refer about Instance management & Transaction in WCF service.

    Wednesday, May 20, 2015 6:04 AM

All replies

  • hi Samuel,
      As per this case, check the following details :
    Per-Call Transactional Service :
      As far as a per-call service call is concerned, transactional programming is almost incidental. Every call on the service gets a new instance, and that call may or may not be in the same transaction Regardless of transactions, in every call the service gets and saves its state from a resource manager, so the methods are always guaranteed to operate on consistent state from the previous transaction or on the temporary yet well-isolated state of the current transaction in progress. A per-call service must vote and complete its transaction in every method call. In fact, a per-call service must always use auto-completion

    Per-Session Transactional Service
      The default transaction configuration of WCF will turn any service, regardless of its instancing mode, into a per-call service. This behavior is geared toward consistency in the service state management, requiring the service to be state-aware. However, having a state-aware service negates the very need for a per-session service in the first place. WCF does allow you to maintain the session semantic with a transactional service. A per-session transactional service instance can be accessed by multiple transactions, or the instance can establish an affinity to a particular transaction, in which case, until it completes, only that transaction is allowed to access it.

    for more information, Click here to refer about Instance management & Transaction in WCF service.

    Wednesday, May 20, 2015 6:04 AM
  • thank you very much.
    Wednesday, May 20, 2015 5:00 PM