Re: Why 'getters' can be bad...

From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 01/09/05 

Date: Sun, 09 Jan 2005 19:34:41 GMT

Responding to Aweston...

>>If one employs a pure data transfer message interface to access the
>>server, the server only needs to block while /it/ is retrieving the data
>>from physical storage.
>
>
> If you do this, then it is not possible to abstract the code to do the
> 'pure data transfer message' with a 'get'. This is because a 'get' is
> actually two requests, those requests being:
>
> I would like x information
>
> and
>
> I would like it returned to me in Y format.

If the server is responsible for formatting the data, then there is only
one request: I need X information in Y format. You can still use an
asynchronous data transfer interface to do that. That allows the server
to provide locking only around the physical retrieval and not around the
formatting operations.

[However, I would be very suspicious about the database server being
responsible for providing alternative formats. Let the DB use the
optimum format for data storage and ad hoc access. Let the clients do
their own reformatting if they need specialized formats.]

>
> So, it is impossible to continue past the get statement until both
> requests are complete If you have a series of many gets, to which the
> underlying code has to query a remote database, you WILL have
> performance problems. Please explain how this can be bottleneck can be
> avoided while still using get's?

That problem completely goes away if you have an asynchronous interface.
  Dealing with asynchronous communications in distributed environments
is why god invented state machines. The actions making the requests
return immediately, allowing the next request to be made while the
server thinks about getting the data for the first request. (Presumably
the server is designed to process request concurrently; let it do its
thing.) Similarly, each response from the server is processed as it
comes in. You can even place each response in its own thread so that
the server responses are processed concurrently by your client, if
necessary.

To put it another way: don't use remote object access across distributed
boundaries. In this case the remote access happens to be a getter, but
the same thing would apply for any responsibility access. Across a
distributed boundary one should not even know that the object with the
getter exists, much less invoke the getter. Doing so invites exactly
these sorts of problems.

*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog (under constr): http://pathfinderpeople.blogs.com/hslahman
(888)-OOA-PATH