Aleksander Slominski wrote:
> from my experience working with APIs that use leases (and having my own
> implementations of such systems as well including grid systems and my
> own XML tuple space implementation): using the concept of a lease to
> maintain garbage collecting of unused distributed resources is very
> enticing but in practice it leads to all kinds of problems.
>
> issues range from deciding on suitable lease duration/renewal policy to
> actually dealing with large failures - it is not great when some
> resources decide to commit "suicide" because lease was not renewed (not
> mentioning possible domino effect) ...
>
> i think that for many application i prefer a more manual cleanup/garbage
> collection (as one could say: some app garbage maybe treasure to others
> :) ).
>
> i found myself often using "forever" leases what leases had to be used
> as a workaround (that is completely defeating purpose of leases ...)
As Dan mentioned, there are some things you have to do initially to make
reasonable configurations of leasing 'start' to work. Then, you might find it
important to tune the configuration over time.
What you'll find is that generally starting with longer times and tuning for
shorter times provides less annoyance. When you are tunning your leasing, you
need to create statistics to help you understand the cause and effect of your
work on the overall performance of the system.
If you are seeing suicide effects and big failures to your system because
important resources are disappearing, as you commented, you might not have
leasing in the right place, or you might not be using it the right way.
Leasing is typically a great match to managing asynchrously created resources.
Especially if those resources have programmatically managed state that controls
their life time (not life cycle, where transactions work better). The leasing
in Javaspaces is good at removing "stale" entries that are not being used.
But, you have to be careful about letting a third party, such as a leasing
system, be in charge of the relationship between two parties which are better
suited to manage that relationship themselves where they can mutually agree on
the state of their relationship.
Gregg Wonderly
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
