Object lifecycle management thoughts ...

[Michael Meeks <michael ximian com>]

Hi all,

	Since there has been much discussion on the topic that I
missed, I thought I'd just wade in 'left and right' :-)

Soeren Sandmann wrote:
> Doesn't both JavaEB and DCOM (or is it COM+? -- I can never remember
> the difference) handle this with leases instead of ref-counting?

	I tend to think that leases are a nice solution to the kind of
problem that DCOM/COM+ and EJBs are aimed at. In a system with
stateless components, where a lease running out is a minor performance
issue rather than a serious loss of data. They are also the only real
way to do 'distributed' object referencing. However, I'd like to
suggest that the case of on-machine ( or on-cluster ), cross process
component software is a different situation to cross-intranet
distributed component systems.

	I don't believe leases are overly suitable as the primary
lifecycle management in many desktop situations. However, having said
that - Monikers _could_ possibly be used to provide nice reliable
references to leased objects.

	Anyhow, consider a large embedded spreadsheet, it is not at
all desirable to have to keep pinging this to determine whether it is
still alive - especialy in a single threaded (STA like) model, the app
can go calculate for a while. Furthermore the consequences of
erroneously destroying what looks like a zombie embedded spreadsheet
will be data-loss.

Colm Smyth wrote:
> 1. middleware notifies server of client death; this is the best
> solution as it is transparent and operates at the a common low
> level; since the middleware is CORBA which (I believe) has no
> standard that supports client death notification, this can't be
> used.

	Well, as you point out, this is the best solution. This is
what I prefer, and how I would like to proceed for Gnome 2.0. To do
this, we will need to seriously blur the line between Bonobo and the
ORB [ keeping the same / a compatible API of course ], and track per
connection/pid lifecycle tracking.

	Since currently Bonobo is used mainly on a single system, and
the evils of cross-system object management are legion it seems to me
reasonable to aim at solving the problem well - only for the local
system case. It is taken as read that the in-proc case is handled by
this transparently.

> 4a) Window; if the object server provides a window that appears within
> a client's frame window, the server knows if the client's containing
> window disappears

	Of course, the bonobo support for this with X windows should
work - we need to fix the bug. FWIR Nat had a long and irksome set of
problems working with this.
       
> My personal vote would be for method 3 as it is guaranteed to work
> for all cases that the middleware supports (local, remote,
> filesystem-independent (in the case of the locking solution),
> windowing-system-independent (works for Bonobo object servers that
> are non-visual)). It also deals with the possibility of a hanging
> client, which method 1 and 4 do not.

	True enough, method 1 will not deal with a hanging client, but
I anticipate that in this circumstance user-intervention seems likely,
killing one end or other.

> 1. one that supports Bonobo ref-counts; this requires per-client
> tracking by the server, which requires that each client invokes a
> register_client() method on each object server that it uses.

	 I think if we were starting again, or designing a nicer
perfect system I would want to expose the raw referencing with all
the information to the underlying system, with something like:

	SensibleRef {
		void acquire (in Object o);
		void release (in Object o);
	};

	So that we have all the ownership information intact in the
API, that can be used ( in future ) for clever things.

	Sadly, we are not starting again - either way, this approach
if good can be layered above the reference counting.
  
> In either case, the server must either: a) instrument *every* method
> call so that the last-invoked time is updated

	Yet another good argument for generic marshaling <sigh>

	So, I think a good solution to the problem is definately only
in the Gnome 2.0 timeframe, and I would prefer to use Method 1.

	Regards,

		Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot