Hello,

After browsing this forum for days, now I am using following framework ...

GUI (local, remote, Internet Client (WinForm) ) BL (Managers, MarshalByRefObj) DAL (LLBLGen - Adapter, Firebird)

But here is a problem i am facing with remoting scenario....

Scenario: I have got an Entity say - CustomerEntity. CustomerEntity has EntityCollections - Orders, OrderDetails, Addresses, etc...

Now, two different users from two different machines (remoting clients) want to access the same object of Customer which is sitting on the remote server. When they acquire customerManager from remoting server, both of them get the same instance of Customer. (as managers are MarshalByRefObj)

But when they acquire customer's Entity, it will make a local copy of customerEntity on each machine. Now, as long as users just look at the data, its all right. But problem starts when they start changing local copy. say user 1 alters five orderDetails and adds two more in. and user 2 deletes two orderDetails and alters three orderDetails.

In my case, any change in orderDetail will require whole CustomerEntity to write back to remoting server.

Now problem is how to keep all the clients in sync?

One solution I can think of is to fire an event for each change on server that forces all clients to re-read all entity data. But this solution will fail when we move our client to run over the internet.

Any ideas for keeping remoting clients in sync?

Thanks,

Kapil

I think you've just described the classic "concurrency" problem.

Even though you are remoting, you can still implement concurrency and let someone know that they are attempting to modify something that someone else has modified.

As far as firing events, this is not something that you would normally do even in a classic 2-tier client/server environment, let alone multi-tier remoting scenario. Although the next version of SQL Server, I understand, will include some kind of notification scheme that facilitates this.

That's a big question

Well you can use the very optimistic approach and let the database handels everything for you, and then you should update clients objects after each save (refetch).

You can implement some concurrency control in the manager clases in the remoting server.

Or you can be more strict and implement some locking techniques in the managers classes, thus preventing clients from updating an object that was locked by another client.

Thanks for your replies.

JimFoye wrote:

I think you've just described the classic "concurrency" problem.

This is indeed a "concurrency" problem. In my previous project, all my objects were MarshalByRefObj. So there was just one copy of object on the server and everyone was sharing the same copy.

With LLBL Entities, which are marshal by val - it makes copies on client machine. As entities have no knowledge of server, the scenario with two clients i have mentioned above ends up in 3 different copies of the same entity.

When user1 updates entites on the server, entities on the server are updated with User1's entities. (where user2 is not aware of this change)

Any update form user2 after that simply overwrites changes done by user1 and makes own copy as current.

The thing i dont understand is in case of remoting/marshalbyVal, how do people keep all clients up-to-date?

JimFoye wrote:

As far as firing events, this is not something that you would normally do even in a classic 2-tier client/server environment, let alone multi-tier remoting scenario.

When i was designing my previous project, i came up to the same problem. The results from Google, Microsoft and books (including Advanced .net remoting by Ingo Ramer), all discussed some kind of implementation for bi-directional channels or implementing client/server on both the sides.

What is the other way of keeping clients in sync?

JimFoye wrote:

Although the next version of SQL Server, I understand, will include some kind of notification scheme that facilitates this.

As far as my understanding (consider me not experienced), we need concurrency resolution at BL level, as we are sharing objects through remoting not the data. And SQL Server will never know about number of clinets, notification scheme is the second thing.

Walaa wrote:

That's a big question

I thought that eveyone using remoting must have faced the same problem !!

Walaa wrote:

Well you can use the very optimistic approach and let the database handels everything for you, and then you should update clients objects after each save (refetch).

As i have mentioned above, we need resolution at BL/Managers level and need to keep clinets in sync. Database dont know about number of clients.

Walaa wrote:

You can implement some concurrency control in the manager clases in the remoting server.

That is infact my original quesiton, but still how to keep clients in sync?

Walaa wrote:

Or you can be more strict and implement some locking techniques in the managers classes, thus preventing clients from updating an object that was locked by another client.

Yes, Letting only one user to access one object at a time is always an option.

Any more help guys? People who are using remoting with LLBL, how they are coping up?

Kapil

My 2 cents:

I'm in the same boat you are. We use LLBLGen, Winforms and Remoting. Right now for our app, the last one wins which means basically our app doesn't have any concurrency control.

Although, I plan on using a 2 stage approach, an Offence and Defence to reduce conflicts.

Defence: Use Concurrecy Predicate Expressions to restrict updates to sensitive data that have been updated since each copy's read time. (We already have an CreatedDate and UpdatedDate on every entity.)

Offence: We will be using bi-directional events from client to server to notify of entity updates. Now this one is tricky as it needs to be scallable and not allow the server to broadcast large events for every single update. I can imagine this being analagous to a large scale denial of service attack on every client. So your event subscription and event broadcasting has to be very efficient which will most likely take some time to architect appropriately.

I'm all ears for any better approaches.

acradyn wrote:

Defence: Use Concurrecy Predicate Expressions to restrict updates to sensitive data that have been updated since each copy's read time. (We already have an CreatedDate and UpdatedDate on every entity.)

I use the 'Defence' technique mentioned above by acradyn in several applications. There is a huge overhead, however, unless the database vendor (Oracle) come up with a something better, I have no choice. This technique give me total control and the overhead is also 'well known'.

In addition, you might want to look at the following desihn pattern as well

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpatterns/html/DesDTO.asp