Seeding and Leeching in TIBCO ActiveSpaces

·         Remember that seeding and leeching is a “per space” state: a process can seed on one space and leech on another.

·         Also remember that a leech is not limited in functionality compared to a seeder, it can make use of all of the Space operations.

·         A Seeder contributes some of its resources to the scalability of the space, and as a “side effect” of being a seeder can experience faster response time on operations on the space(s) it seeds on:

·         If the key value is either seeded or replicated, then any operation to read it will be faster because it will not involve interacting with another seeder process (and therefore no network round trip is required).

·         If the entry is seeded, any operation to modify the entry (insert, update, delete) is faster.

o   If the replication degree for the space is greater than zero, the operation will involve sending the replication request to another seeder process.

o   If there is synchronous replication, however, the operation will not return until it has been replicated, meaning a replication request is sent to the replicating seeder(s) and an acknowledgement is received.

·         Every time a seeder joins or leaves, a space it triggers redistribution (in the case of a join) or re-replication (in the case of a leave) of some of the entries in the space.

o   If a process joins a space as a seeder, it should be relatively stable over time (i.e., should not join and leave the space repeatedly).

o   To minimize the impact of redistribution (or re-replication) on ongoing operations on the space, redistribution occurs as a background operation, which means that it can take some time to complete.