Re: Synchronization in .Net Remoting

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

From: Sam Santiago (ssantiago_at_n0spam-SoftiTechture.com)
Date: 08/26/04 

Date: Thu, 26 Aug 2004 09:37:34 -0700

If you can post some code that would probably make things more clear. Have
you considered how you would handle deadlocks? If you need distributed
transactions you might consider EnterpriseServices vs. trying to implement
your own locking mechanism.

Thanks,

Sam 

-- 
_______________________________
Sam Santiago
ssantiago@n0spam-SoftiTechture.com
http://www.SoftiTechture.com
_______________________________
"Chun Fan" <ChunFan@discussions.microsoft.com> wrote in message
news:7B1718AD-2951-44C1-9E4C-5DFFDBBA615A@microsoft.com...
> Thanks for your answer. If the client doesn't need to acquire several
> different locks on different remote objects before performing any real
> processing work, it is a good idea to control the syncrhonization strictly
on
> the server side. Actually, I am implementing a two-phase locking like
> application. So at the first phase, the client should acquire all the
locks
> (which may on different remote objects), then the client can perform some
> processing at its side, after that, the client should release all the
locks
> have been acquired. The locks may on different server/remote objects so it
is
> necessary for the client to control the lock. However, the actual locks
are
> on the server side.
>
> Secondly, the InitializeLifetimeService method has been overrided to
return
> null and that didn't solve the problem.
>
> And now the problem is that if I do NOTHING after the clients start, after
2
> ~ 5 minutes, the blocking mechanism works smoothly. However, if I let the
> clients access the remote objects from the beginning, the blocking doesn't
> work. And if I stop allowing the clients to access the remote objects for
a
> while, the blocking can work again. So any suggestions to solve this?
Thanks
> a lot!
> "Sam Santiago" wrote:
>
> > What are you doing within your Singleton object that you need
> > synchronization?  I do not think it's a good idea to have your clients
> > control the synchronization, especially via a remote method call.  This
> > pushes the responsibility of synchronization management to the client
which
> > assumes all your clients will be coded properly.  A single badly coded
> > client could cause your entire server object to become unusable by any
other
> > clients - too big a risk.
> >
> > I recommend having the synchronization management done strictly server
side.
> > Your clients should simply acquire a reference to your Singleton an
execute
> > the needed method.  Your Singlton should on the server side within  the
> > methods that need synchronization use a Monitor to synchronize the
> > appropriate activity.
> >
> > Lastly, if you want a true Singleton be sure to override the
> > InitializeLifetimeService method provided from the MarshalByRefObject to
> > return null.  Some of the behavior you're observing might be due to the
fact
> > that your object's lifetime lease has expired (5 min default from the
last
> > method call) and a new object is created when you invoke your SAO after
a
> > few minutes.
> >
> > Thanks,
> >
> > Sam
> >
> > -- 
> > _______________________________
> > Sam Santiago
> > ssantiago@n0spam-SoftiTechture.com
> > http://www.SoftiTechture.com
> > _______________________________
> > "Chun Fan" <ChunFan@discussions.microsoft.com> wrote in message
> > news:6A4EFDFB-72F1-4940-838D-383DDC03CF6A@microsoft.com...
> > > More information I got:
> > > If I do nothing after starts the client, i.e. not trying to access the
> > > remote object, for several minutes, the blocking mechanism works
smoothly.
> > > Anyone can give me a hand to let me know what's wrong here? Is that my
> > > program error or a bug of .net framework? Thanks a lot!
> > >
> > > "Chun Fan" wrote:
> > >
> > > > hi, there,
> > > >
> > > > I am recently using .net remoting to develop a distributed
application
> > and
> > > > some synchronization problem bothered for a long time.
> > > >
> > > > The problem looks as following:
> > > > There is one server application that hosts a remote object,
"mydata".
> > This
> > > > remote object is configured as a singlton object. Three functions
are
> > > > developed within this object to provide synchronized data access:
> > > > public class MyData :MarshalByRefObject{
> > > >
> > > > ...
> > > > public void Lock(){
> > > >       System.Threading.Monitor.Enter(this);
> > > > }
> > > >
> > > > public void Release(){
> > > >       System.Threading.Monitor.Exit(this);
> > > > }
> > > >
> > > > public bool TryLock(){
> > > >       return System.Threading.Monitor.TryEnter(this);
> > > > }
> > > > ...
> > > > }
> > > >
> > > > And two client applications with similar behavior that at first,
each
> > client
> > > > application tries to obtain the lock on mydata by invoking
> > mydata.Lock();
> > > > then does some processing. After the processing is done, the client
will
> > > > display a message box by invoking 'MessageBox.show()' and waiting
for
> > user's
> > > > input. After the user's input is received, the client will invoke
> > > > mydata.Release() to release the lock on mydata such that other
clients
> > may be
> > > > able to access mydata.
> > > >
> > > > So I started the first client. The client obtained the lock and
> > displayed
> > > > the message box, waiting for my input. Then the second client was
> > started. If
> > > > everything were working, the second client should have been blocked
> > since it
> > > > can not obtain the lock. Unfortunately, the second client just went
on
> > as if
> > > > it had got the lock and also displays the message box!
> > > >
> > > > The more wierd thing was that after a random length of time(several
> > minutes
> > > > to hours), the lock could work!, i.e. before one client releases the
> > lock,
> > > > the other one is blocked at the mydata.Lock() invocation!
> > > >
> > > > So could anybody help me to tell me what's wrong here? Or anybody
can
> > tell
> > > > me how to implment such a locking in the .net remoting? Thanks a
lot!
> > > > -- 
> > > > Sincerely
> > > >
> > > > Chun
> >
> >
> >

Relevant Pages

  • Re: Synchronization in .Net Remoting
    ... the client should acquire all the locks ... (which may on different remote objects), then the client can perform some ... > control the synchronization, especially via a remote method call. ...
    (microsoft.public.dotnet.distributed_apps)
  • Re: Synchronization in .Net Remoting
    ... the related server side object code has been posted. ... > is the related client side code: ... > the locks before doing processing and then release all the locks. ... >>> different locks on different remote objects before performing any real ...
    (microsoft.public.dotnet.distributed_apps)
  • Re: Synchronized objects
    ... > proxies to remote objects and the appropriate one to use depends on how ... > plan to use the object in your clients and on your server. ... > 1) Does every client that connects need to access the same Foo instance ...
    (microsoft.public.dotnet.framework.remoting)
  • Re: lost responsiveness
    ... > objects are in the same dll. ... > the host runs with all the responsiveness. ... > when the existing clients try to access one of the 4 remote objects again, ... > try to run an additional client. ...
    (microsoft.public.dotnet.framework.remoting)
  • Re: remoting & security.
    ... authentication of clients you might want to host your remote objects in IIS. ... object of the client. ... Sam Santiago ...
    (microsoft.public.dotnet.framework.remoting)