.NET Remoting thread locking mechanism

Question

Hello all,

I'm having a pressing issue and I'm hoping you all can help me out. I will try my best to explain it as well as I can.

I am augmenting a system that uses .NET remoting to allow for database calls from a thin client to a server that executes said calls. The server itself has the data access components installed on it, so it makes the actual calls to the database, and just returns the datarows to the thin client.

I just recently added transactions to these modules. I wanted to make this thread-safe, where if client thread A started a database transaction, client thread B would not be able to access client thread A's transaction. It is not necessary to allow client thread B to have it's own transaction in the meanwhile, only necessary that I do not allow client thread B to use client thread A's transaction.

There is only 1 reference to the remoting object that both of them share, and because of the underlying architecture that I will not get into, I am not able to change this. All of the Transaction objects are stored on the server in this remoting object.

I see no good way of doing this, besides perhaps passing the client thread information along with every single transaction call, which is not feasible with my pressing timelines. :-( Perhaps if the remoting object could access the calling client thread, then I would not have to pass the thread information with every call, making this feasible.

If there was some way of associating a client thread with a remoting process thread, I think that would do the trick, but there is no documentation that I could find on such a thing.

I hope I explained this well enough. All help is greatly appreciated. Thank you in advance.

Answer 1

I am not 100% sure if this can be done, but using the CallContext may help. In a nutshell, a CallContext is an Out-Of-Band data that can be remoted across to the server, see this blog here for an example. If you do not understand what an Out-Of-Band (oob) is, look here on wikipedia. Here's another concrete example here. That may give you the clue.

Hope this helps, Best regards, Tom.

Answer 2

What you're trying to do sounds kinda weird so let me see if I understand:

• You're using a singleton on the server side this is why each client has only 1 thread on the server.

• Assuming that the transaction process takes a long time (seconds to minutes) the other clients MUST wait until the first client has finished.

I think but I'm not sure that each client's call is creating it's own thread. If this is true then simply implementing some "lock" calls when the remote object needs to make thread safe calls should do the trick. Locking is expensive and if the transaction is taking seconds then the other guy waiting might timeout (eeK!)

This is the kind of stuff that the TransactionScope object was built for (See MSDN). I can't really assist anymore without knowing more about the arch of the solution.

Sorry... I don't know if this is useful or not.