HighTechTalks DotNet Forums  

Switching to local data objects when Remoting fails

Dotnet Framework (Remoting) microsoft.public.dotnet.framework.remoting


Discuss Switching to local data objects when Remoting fails in the Dotnet Framework (Remoting) forum.



Reply
 
Thread Tools Search this Thread Display Modes
  #1  
Old   
Ekin Caglar
 
Posts: n/a

Default Switching to local data objects when Remoting fails - 10-01-2006 , 10:34 AM






Hi everybody,

Here is the scenario: We have a number of web servers and although each one
has a copy of the business objects required by our application, they connect
and get their data from a Remoting server. (Benefits include centralized
caching, single db access point, etc.)

This works fine unless the Remoting Server fails. In case of such a
failure - e.g. if the client cannot connect to the server or if there is an
error on the server - we want the clients to be able to switch to using
their local copy of the business objects without human intervention.

How can we do this? Any suggestions?

Cheers,

Ekin



Reply With Quote
  #2  
Old   
Spam Catcher
 
Posts: n/a

Default Re: Switching to local data objects when Remoting fails - 10-01-2006 , 04:02 PM






"Ekin Caglar" <ekin (AT) sibilo (DOT) co.uk> wrote in
news:eDXqwaW5GHA.1200 (AT) TK2MSFTNGP02 (DOT) phx.gbl:

Quote:
This works fine unless the Remoting Server fails. In case of such a
failure - e.g. if the client cannot connect to the server or if there
is an error on the server - we want the clients to be able to switch
to using their local copy of the business objects without human
intervention.
Are your business objects located in a common layer (DLL) that the client
has access to?

In this case:


Try
If DisconnectedFlag = False Then
MyObject = RemoteServer.GetSomeObject()
Else
MyObject = LocalFetch.GetSomeObject()
End If
Catch ex as exception
MyObject = LocalFetch.GetSomeObject()
DisconnectedFlag = True
End Try

Since the objects are located in a common layer - it doesn't matter who
creates the objects or where the objects are created.


Reply With Quote
  #3  
Old   
James Westgate
 
Posts: n/a

Default Re: Switching to local data objects when Remoting fails - 10-04-2006 , 08:59 AM



Looks like you need to employ the "Class Factory" pattern. This is a
class that returns class instances to you. You can let the factory
decide what style object it provides based on the available resources.

Class factories are also highly recommended for use in remoting
scenarios where you dont want to share the business object layer.

James

http://www.crainiate.net


Ekin Caglar wrote:
Quote:
Hi everybody,

Here is the scenario: We have a number of web servers and although each one
has a copy of the business objects required by our application, they connect
and get their data from a Remoting server. (Benefits include centralized
caching, single db access point, etc.)

This works fine unless the Remoting Server fails. In case of such a
failure - e.g. if the client cannot connect to the server or if there is an
error on the server - we want the clients to be able to switch to using
their local copy of the business objects without human intervention.

How can we do this? Any suggestions?

Cheers,

Ekin



Reply With Quote
  #4  
Old   
Ekin Caglar
 
Posts: n/a

Default Re: Switching to local data objects when Remoting fails - 10-09-2006 , 05:48 PM



We already use a Class Factory pattern but the problem arrises when the
remoting server fails. Take the following example:

I register MyObject on application startup as a client activated object.

I can get an instance of the object using
(MyObject)ClassRepository.GetObject(objtype, id)

I then switch off the remoting server and the errors start. When I try to
access the object or create a new instance, I get a "No connection could be
made because the target machine actively refused it" error.

Is there a way to check the status of the RemotingServer and
register/unregister CAOs accordingly?

Ekin

"James Westgate" <nospam (AT) crainiate (DOT) net> wrote

Quote:
Looks like you need to employ the "Class Factory" pattern. This is a class
that returns class instances to you. You can let the factory decide what
style object it provides based on the available resources.

Class factories are also highly recommended for use in remoting scenarios
where you dont want to share the business object layer.

James

http://www.crainiate.net


Ekin Caglar wrote:
Hi everybody,

Here is the scenario: We have a number of web servers and although each
one has a copy of the business objects required by our application, they
connect and get their data from a Remoting server. (Benefits include
centralized caching, single db access point, etc.)

This works fine unless the Remoting Server fails. In case of such a
failure - e.g. if the client cannot connect to the server or if there is
an error on the server - we want the clients to be able to switch to
using their local copy of the business objects without human
intervention.

How can we do this? Any suggestions?

Cheers,

Ekin



Reply With Quote
  #5  
Old   
Ekin Caglar
 
Posts: n/a

Default Re: Switching to local data objects when Remoting fails - 10-09-2006 , 05:49 PM



Yes, the business objects are located in a common layer (DLL) that the
client has access to.

How do you implement the LocalFetch?

MyObject is already registered as a client activated object and if you try
to create it, it will be fetched from the remoting server. And if the
remoting server goes down for some reason, the fetching fails.

Ekin

"Spam Catcher" <spamhoneypot (AT) rogers (DOT) com> wrote

Quote:
"Ekin Caglar" <ekin (AT) sibilo (DOT) co.uk> wrote in
news:eDXqwaW5GHA.1200 (AT) TK2MSFTNGP02 (DOT) phx.gbl:

This works fine unless the Remoting Server fails. In case of such a
failure - e.g. if the client cannot connect to the server or if there
is an error on the server - we want the clients to be able to switch
to using their local copy of the business objects without human
intervention.

Are your business objects located in a common layer (DLL) that the client
has access to?

In this case:


Try
If DisconnectedFlag = False Then
MyObject = RemoteServer.GetSomeObject()
Else
MyObject = LocalFetch.GetSomeObject()
End If
Catch ex as exception
MyObject = LocalFetch.GetSomeObject()
DisconnectedFlag = True
End Try

Since the objects are located in a common layer - it doesn't matter who
creates the objects or where the objects are created.



Reply With Quote
  #6  
Old   
Spam Catcher
 
Posts: n/a

Default Re: Switching to local data objects when Remoting fails - 10-09-2006 , 10:24 PM



"Ekin Caglar" <ekin (AT) sibilo (DOT) co.uk> wrote in
news:eEoabz#6GHA.1256 (AT) TK2MSFTNGP04 (DOT) phx.gbl:

Quote:
MyObject is already registered as a client activated object and if you
try to create it, it will be fetched from the remoting server. And if
the remoting server goes down for some reason, the fetching fails.

Don't register the objects in the .config file? Rather create them as
needed with Activator.GetObject (or declare them as local objects if the
remoting connection fails).




Reply With Quote
  #7  
Old   
Ekin Caglar
 
Posts: n/a

Default Re: Switching to local data objects when Remoting fails - 10-10-2006 , 10:26 AM



That means refactoring tens of thousands of lines of code (100+ classes that
are instanciated numerous times all around the code)...

Any easier way?

E

"Spam Catcher" <spamhoneypot (AT) rogers (DOT) com> wrote

Quote:
"Ekin Caglar" <ekin (AT) sibilo (DOT) co.uk> wrote in
news:eEoabz#6GHA.1256 (AT) TK2MSFTNGP04 (DOT) phx.gbl:

MyObject is already registered as a client activated object and if you
try to create it, it will be fetched from the remoting server. And if
the remoting server goes down for some reason, the fetching fails.


Don't register the objects in the .config file? Rather create them as
needed with Activator.GetObject (or declare them as local objects if the
remoting connection fails).





Reply With Quote
Reply




Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.4
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.