.NET Remoting Thread Locking Mechanism

Question

I have a real problem and I hope you all can help me. I will try my best to explain this as I can.

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

I 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 the client thread transaction. There is no need to allow client stream B to have its own transaction at the same time, it is only necessary that I do not allow client stream B to use the transaction of client stream A.

There is only 1 link to the remote object that they share, and because of the underlying architecture, which I will not get into, I cannot change this. All Transaction objects are stored on the server in this remote object.

I don’t see a good way to do this, besides, perhaps transmitting information about client flows along with each transaction call, which is impossible for my urgent terms. :-( Maybe if a remote object can access the flow of the calling client, then I don’t it will be necessary to transmit flow information with each call, making this possible.

If there was some way to associate a client flow with a remote process flow, I think that would do the trick, but there is no documentation that I could find in such a situation.

I hope I explained it quite well. All help is much appreciated. Thank you in advance.

Answer 1

I am not 100% sure if this can be done, but using CallContext can help. In a nutshell, CallContext is the Out-Of-Band data that can be moved to the server, see this blog post here for an example. If you don’t understand what Out-Of-Band (oob) is, check out wikipedia here . Here is another specific example here . This may give you a clue.

Answer 2

What you are trying to do sounds strange, so let me see if I understand:

• You use a singleton on the server side, so each client has only 1 thread on the server.

• Assuming the transaction process takes a long time (from a few seconds to several minutes), other clients MUST wait until the first client finishes.

I think, but I'm not sure that each client call creates its own thread. If this is the case, then it is simple to implement some “blocking” calls, when the remote object must create thread-safe calls, it must do the trick. Locking is expensive and if a transaction takes a few seconds, another waiting one may time out (eeK!)

This is the material that was created for the TransactionScope object for (see MSDN) . I can no longer help without knowing more about the solution arch.

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