To answer some of your questions:
1. Yes. You will need to specifically do a put whenever your object has been modified.
2. Replication takes place for the whole myVector in your case.
(This is where TreeCacheAop comes where you can do fine-grain replication.)
3. SFSN will manage the state change for you vs. you will need to manage yourself (unless again you are using aop for fine grain replication).
4. We have some old numbers on 2 nodes replication. But it's outdated so we will be working with new ones now.
Thank you for the quick response Ben. That helps. My main concerns are in the area of performance.
From what I read, if I use the cache loader, then every single node is persisted on a backend store. Correct? Will that not be a big dent on performance?
What if I dont have/want a cache loader? Will the nodes still get evicted? If so, am I losing those values? What happens if I dont have a cache loader, and node gets evicted, and a client asks for those values?
When will the nodes get evicted if I set the max number of nodes to 0 (unlimited)? Is there a memory limit that I can set?
Is it possible to only persist the evicted nodes into the persistent store instead of all the nodes? This would be like the passivation of a session bean.
I apologize if any or all of my questions are naive.
1. Yes, using cacheloader implies every put is persisted so it has performance implication.
2. If the node is evicted and not persisted, it will return null. So it is application responsibility to check this.
3. We have overflowing persistence (or passivation) feature in our roadmap.
Thank you. I would like to know about some production level deployments.
How many nodes, (with small objects associated) is typically recommended in a tree cache? Maybe a range would give me a better idea.
Are there any best practices for using TreeCache?