CODEWITHSUNDEEP
asp.netwcfnhibernateconcurrency
Gopal
Gopal

Reputation: 265

ASP .NET,concurrency control with WCF

I would like to take advise from all of you based on your experience with SOA based architecture and how to achieve concurrency control with WCF and nHibernate.

  1. ASP .NET (web app) - 1 tier (Web server)
  2. WCF+nHibernate - 2nd tier (Application server)

Scenario1

a. User1 has now opened an Order and Edits it. b. User2 in meantime opens the same Order and Edits it.

How do we prevent User2 from performing this operation. Both WCF calls to "edit order" fetches the record using different nHibernate sessions as the application server is designed to be stateless.

How do I configure nHibernate/WCF to handle this kind of scenario?

Scenario2

If entering an order involves multiple pages; with pages getting displayed based on business logic (WCF calls to determine next page) should the order data be maintained at Web Server (ASP .NET) across these pages and posted on each WCF call taking care of the order business logic? Is my thinking right?

I'm aware of the other way to do it, which is to create a temporary order record to maintain intermediate data across pages/WCF calls.

Upvotes: 2

Views: 446

Answers (1)

casperOne
casperOne

Reputation: 74560

In regards to the first scenario, you don't want to block the user from attempting to make an edit; your system will never scale if you try and enforce pessimistic concurrency.

Rather, you want to use optimistic concurrency; your models would have a timestamp (usually an actual date time value, or better yet, some sort of binary value guaranteed to be unique for the particular context/table). Most ORMs (including nHibernate, I am sure) have support for optimistic concurrency; when generating the update, it will only update the record if the primary key is the same and the timestamp are the same, if it isn't, then you know that someone else edited the record since the last time you fetched the data.

For your second scenario, you might want to consider Windows Workflow, which has tight integration with WCF. Generally though, I'd have a separate table which contains the incomplete order information along with a key that the user can use (perhaps the session id) to look up the data.

Only when you know the order is complete do you move the data from your "staging" table over to your real orders table.

Upvotes: 3

Related Questions