Member.getID(), Member.getUID(), Members as cluster cache keys and values

Question

My cluster application needs to do some bidirectional mappings via coherence between
coherence members and application entities.
What we have now are mappings that use Member.getID() integers.
When we need to dispatch logic to Members hosting an entity
we'll use InvocableService.{execute,query}() with a member set derived by use of
ServiceInfo.getServiceMember() for the int member ID's we have.
My concern is that if we have delays or other snafus in membership event processing
that the member id's returned by getID() will be recycled and refer to a different cluster member.
For example, if our event listener is down for some time, when it comes back up there may be
entries in the cache whose member ID's were recycled, at least that's my fear.
For our logic that would be bad. We'd assume we had entity assignment to a member
that has actually disappeared.
I could potentially use Member.getUID(), but that doesn't guarantee a unique
identifier, and so like a hash I wouldn't use it as the sole key where an unambiguous
resolution is required.
I was just looking for advice on anternatives or pitfalls of having caches
keyed or valued by cluster Members in whatever way works best.
We have a set of resources where want to apply our own membership distribution policies
according to a complex algorithm applied to whatever the cluster topology du jour may be,
so just allowing coherence maps to do the partitioning for us is not an option in this case.

Answer 1

I haven't had any problems with it yet, but the facility is still in development.
Being armed with a bit more information now can save a lot of headaches later.
The information you provided should be enough to help me avoid problems.
The only issue for me being that we're still running version 3.5, but presumably the UID format
you described was the same in 3.5 too.
Thanks much!