Eric Hodel <drbrain / segment7.net> wrote in message news:<20040618220336.GK96045 / segment7.net>...
 [ cut ]
> This is an example of what not to do:
> 
> class RemoteObj
>   include DRbUndumped
>   ...
> end
> 
> class Server
>   def get resource
>     return RemoteObj.new
>   end
> end
> 
> DRb.start service nil, Server.new
> 
> In this case the server will return to the client a resource that will
> dissappear after the GC gets run.  DRb has a mechanism to handle this,
> id conversion, so that remotely referenced objects have a chance to stay
> "alive" longer than the GC would let them.  Look at DRb::TimerIdConv
> compared to DRb::DRbIdConv.  (For those of you not following along at
> home, TimerIdConv uses a time-since-last-access to recycle remote
> objects, while DRbIdConv uses ObjectSpace to retrieve objects.)
> 
> You could extend DRb::TimerIdConv to delay shutting down the DRb server
> until after all remote objects expire.  Unfortunately, this brings you
> to the choice of either waiting a long time to complete application
> shutdown, or shutting down before the client processes are done with the
> references.

Thanks for the explanation.
This was approximately what I was doing, and I was worried about this.
I'm returning results from queries to a Postgresql database, and PGresult
objects cannot be marshalled (I'm not sure why).
In practice all clients fetch the results immediately, so it seemed to work
fine, but I want something safer. Maybe creating a dumpable PGresult is the
easiest way to go, but TimerIdConv with a short timeout would also work.
I wonder what happens if a client references a CG removed object: it this
is well-defined I could also re-issue the query in a rescue. The chance
of this happening is quite small after all.

Cheers,

Han Holl